Fórumok
Sziasztok.
Míg Slackware 14.2 alatt egy tisztességesen telepített ghostscript tökéletesen renderel, addig egy legújabb linux Mint-en ugyanazt 5 perc helyett 40-50 percig készíti el. A keletkező átmeneti állomány mérete mindkét esetben 1.2GB körüli méret.
Valami súlyos gond lehet, de nem tudom, micsoda. Az eredmény amúgy ugyanaz, semmi minőségbeli anomália.
Hozzászólások
Hm... mar az 5 perc is igencsak sok, vsz ott valami mas gond (is) van. Mire rendelelteted ki? x11-re vagy pdf-re vagy valami bitmapre?
Előbb dvi-re, majd a dvi-t pdf-re. Csak latex fordítót használok.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Az oke, de mivel nezed meg a pdf-et? Ha jol ertem, azt nezed meg ghostscript-tel. Legalabbis sem a *.tex-et, sem a *.dvi-t nem lehet azzal megnezni.
Mit is csinálsz pontosan? Egy dvi-ből készült pdf valószínűleg raszteres betűképeket fog tartalmazni, egy nagyobb fájlnál ez rendesen megakaszthatja a gs-t a megjelenítésnél. Valami rémlik, hogy a dvi konvertálásnál ugyanúgy le kell renderelnie a dvi fontokat mint a megjelenítésnél, ez először nagyon sokáig tarthat egy nagyobb, összetettebb doksinál, ez is lehet a magyarázat, ha a dvi-pdf konverzió ideje a hosszú (itt valszeg nem a gs a lassú).
Amúgy emlékeim szerint ha a pdf a cél, akkor érdemesebb egyrészt postscript vagy egyéb vektoros fontokat használni, másrészt pdftex/pdflatex-el fordítani egyből pdf-be, van oka, hogy nem így csinálod?
Minden font vektoros.
pdflatex (vagy egyéb) fordítót pedig azért nem használhatok, mert rengeteg csomagot ki kellene iktatnom. Amiket használok, az mind kell.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Végső esetben ránézni strace-szel, hogy mit csinál, adott esetben mire vár?
Erről még nem hallottam, ma megnézem, mi ez...
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Akkor: ps -ef | grep folyamat (gondolom ghostscript), ekkor látod a PID-jét is, majd strace -p PID (amit az előbb szedtél ki). Persze futás közben nézd. :)
Folyamatosan ez van:
Mintha karakterenként olvasna valamit, ez jó hosszú ideig tolódik.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Ezekhez a folyamatokhoz (ghostscript) kicsit sem értek, de ebből nagyon úgy tűnik, hogy nagyon lassan, tényleg karakterenként olvassa be, ami semmiképp sem tűnik gyakorlati szempontból vállalhatónak ilyen tempóval. Downgrade vagy hasonló nem játszik?
A Downgrade azmiaz?
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
A ghostscript downgrade-je korábbi verzióra, amire gondoltam.
Azt még ellenőriznem kell, hogy ezen a distriben hogyan kapcsolódik a telepített gs a Texlive-hoz. Ott még lehet kavarodás.
Egyszerűen érthetetlen számomra, hogy a debianok miért nem képesek a teljes Texlive rendszert betolni az /opt-ba, és ott kezelni. Minek szemetelik tele a bin könyvtárakat? Hogy minden áttekinthetetlen legyen?
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
off, de nem mindegy, hova "szemetel"?
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Szerintem nem. Legyen minden áttekinthető...
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Ami neked áttekinthető, az a csomagkezelés szempontjából nem az. Van erre jópár szabály, debianokon (is, meg kb minden ismertebb disztrón) a csomagkészítésnek is vannak előírásai, amik ezt hozzák. Megkerülheted a csomagkezelést, felrakhatsz kézimunkával vagy egy adott program telepítőjével csomagokat az /opt alá, de egyrészt ebből keveredés lehet, másrészt innentől a csomagkarbantartás, update a te dolgod. A slaki ezt kicsit másként értelmezi, ott ezért nincs teljesen így.
Erről itt is olvasgathatsz.
Az hogy a teljesítmény adott esetben eltér egyes disztrókon az épp függhet attól, hogy mire, milyen paraméterekkel fordították, mik a default beállítások, etc. Meg persze attól is, hogy épp milyen verziókat telepít. Ha munkára rendszeresen használod akkor érdemes lehet akár csak ezért egy külön rendszert tartani és behangolni neki, persze ahhoz tapasztalat kell, hogy kiválaszd a megfelelőt - mondjuk a slaki pont jó lehet :) de nálam rutinosabbak talán dobnak még be erre tippet.
Szerk: szerintem sok időt nem érdemes hibakeresésre fordítani ha a disztró csomagokkal alapból nem megy rendesen, bár tanulságnak érdekes lehet.
A Texlive distribet a 2020-as verziónál fagyasztottam ki a frissítésekből, mert nem akarom, hogy egy verziófrissítésnél a texlive új finomságai szétbarmoljanak valamit. (Horgonyok, abszolút pozíciós ketyerék, egyebek...)
Szóval jó okom van a teljes texlive optba rakását, és még azt is megcsinálnám, hogy squashfs-t alkotok belőle.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Ezesetben nem ártana köréfagyasztani azt a keretrendszert is amin jól működött, ghostscripttel, meg annak minden függőségével, stb.
Ez az, amihez nem értek. Valami APPIMAGE vagy mi valósítana meg ilyet. Még azt is meg lehet állítólag csinálni, hogy az egykori CorelLinuxból kiszedi az ember a Corelt és appként üzemelteti a 21 éves grafikai progit. Ugyanezt egy teljes texlive-val megtenni fergeteges lenne, mert akkor hordozhatóvá válna az egész, akár évtizedeken át.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
emlekeim szerint a corel linuxban nem volt coreldraw... es amig letezett coreldraw linuxra, az is libwine-os volt, gyak. a windozost futtattak linuxon. az utolso nativ verzio a motif-os 3.5 volt 30 evvel ezelott...
Lassan ideje előszednem... Nekem még megvan cédén...
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Én a slackware-n is megnézném összehasonlításképp
Azt este fogom megnézni, kíváncsivá tett ez a stackmicsoda...
Ott egyébként még az xdvi is gyorsabban hozza be az oldalakat.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
A gs_num_rendering_threads értékének módosítását próbáltad?
https://www.accountkiller.com
http://fczbkk.com/current-state-of-webdesign/
Nem próbáltam, azt sem tudtam, hogy létezik ilyesmi.
De ahogy a doksikat nézem, egyelőre nekem kínai a ghost minden eleme.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
dvipdf -dNumRenderingThreads=40 file.dvi
Így próbálkoztam, hátha.
De nem sikerült a gyorsabb renderelés.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
Ez a keletkező 1,2 gigás átmeneti állomány pontosan micsoda? Mi a kiterjesztése? Hány oldalas pdf doksiról van szó?
Egyébként nekem az 5 perc is soknak tűnik, nem hogy a 40-50. Még ha egy egész könyvről is van szó, akkor egy releváns gépen le kéne gyúrnia dvi-ba vagy pdf-be 1+1 perc alatt max, de még ez is elég pesszimista becslésnek tűnik.
“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧
700 oldal feletti. Átmeneti állománytónak nincs kiterjesztése (legfeljebb windowsoknál). A /tmp könyvtárban a *gs* tartalmú fájlok növekedését figyelem, amikor elkezdi a renderelést, így figyelem, mikor mekkorára növekszik, és így becsülöm meg, mennyi idő van még hátra.
DVI-ba pár perc alatt lefordul. A dvipdf a hosszas folyamat.
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.