Hogy lehet belenyúlni az OS rendszerbetű készleteibe?
Az apropó amiért ilyen “veszélyes” manőverbe kezdenék:
Anno adódott egy nyomtatási problémám PDF fileokból (aminél a pdf készítő forrást nem tudom befolyásolni). A gépen megnyitott pdf doksiban még megfelelően mutatkoztak a karakterek, de a jellemző magyaros bötűk már nyomtatáskor eltűntek… Ez volt az: Azonnali kérdések
Azóta nem foglalkoztam nagyon a dologgal, mivel Mojave alatt működött. De közeledik a pillanat, hogy nem fogok tudni már downgrade-elni Mojave-ra (újabb géppel), viszont a probléma még adott.
A doksi Arial betűtípussal érkezik a forrástól. Megnyitáskor, megtekintéskor még oké, de amint belenyúlok a pdf-be (mittomén… teszek bele egy karikát a Preview app-al), bezárást követően már láthatóan megváltozik az addigi Arial fontkészlet valami gyanúsan más Arial-ra hajazó de látszatra is más fontkészletre s ezzel együtt eltűnnek a hosszú ékezetes karakterek.
Na erre találtam azt ki, hogy próbára kiütném az OS-el gyárilag érkező Arial fontcsaládot egy olyanra amiről biztosan tudom hogy jó.
…de nem tudok törölni, helyettesíteni a system-ben a fontok mappájában.
Kapcsold ki a SIP-et, ezutan tudod piszkalni 10.14-ig a /System -et, a piszkalas utan a SIP visszakapcsolhato. 10.15-ben is ugyonez kell, de a /System ott mar readonly, tehat ujra kell mountolni read-write modban. 11-tol pedig mar digitalis alairas is vedi, azt is ujra kell generalni, viszont itt mar a SIP nem kapcsolhato vissza.
De azota eltelt egy csomo ido, kiprobaltad Big Sur alatt is, friss driverekkel?
Szerk: Egyebkent, en a helyedben inkabb a PDF-et szednem darabokra es megprobalnek rajonni, hogy mi a baja… Meg megneznem az osszes fontra, tartalomra, optimizaciora vonatkozo beallitast a printerdriverben, hatha ott is kiugrik a hiba.
Most Big Sur-on próbálkoztam vele… Biztonság kedvéért lekaptam a legfrissebb Epson driver-t, de szerintem nincs összefüggésben a kettő.
Ha a “forrástól (kormányzati weboldal)” letöltöm a pdf-et, megnyitom - tökéletesen jelenik meg a tartalom. Amint Preview-ban teszek egy szerkesztést és bezárom, az újbóli megnyitás során már hibásan jelenik meg. Tehát még effektív nyomtatásról szó sem volt. Ha nem szerkesztem és elküldöm nyomtatásra, ugyanúgy hibásan jeleníti meg.
Bármilyen app-ban megnyitva (Illustrator…stb) semmi gondja vele. De az ilyen kerülőutakat elfelejteném, mivel 50-100db különböző pdf doksi nyomtatásra küldése órákkal tolódna ki (az eddigi pár perc helyett).
Nem azt mondom, hogy egyesevel… Hanem ki kene deriteni, hogy mi a baja a pdf-nek, hogy meg lehessen oldani.
ha kijelolsz benne szoveget, amiben van olyan karaker, ami eltunik, a kijeloles “jol nez ki”? ha copyzod-pastezod, jo lesz?
tuti, hgy betuket latsz es nem vonalakat?
Ezt pl azert kerdezem, mert lattam mar olyan pdf-et, amit nem tudtunk nyomtatni Macen, mert nem voltak benne ekezetes betuk. A pdf tartalmazott “szoveges” reszt es tartalmazott “vonalakat”. A betuk rajzolata, amit lattal nem a betuk voltak onmaguk, hanem pathok, kiszinzeve feketevel. Ha megneztuk a “szoveget” a betuk mogott, ott nem voltak ott az ekezetes karakterek. Tehat ott “space” volt a szovegben. Az OSX pedig okosan nyomtat Catalina ota, ha okos a nyomtato. Odaadja neki a fontfilet, es a szoveget, hogy nesze nyomd ki. Tehat ha a pdf-ben pathok vannak, es mas a szoveg, akkor ebol hulyeseg lesz.
Szoval meg kellene nezned jobban azt a pdf-et, hogy kideruljon mi a baj vele. Az alapjan lehet ossze lehet rakni valami “automata” processzt, amivel ki fogod tudni nyomtatni.
A kijelölés menete/dinamikája/mérete/színe minden stimmel. Pont ugyanolyan mint a szöveg más részében.
Copy és paste tökéletesen működik a letöltött pdf-ből. Tehát bárhová illesztem a szöveget, mindenhol tökéletesen azt a karaktert adja vissza mint amit “látni”.
Korábban már én is találkoztam ilyen karakter-mizériával (talán pont az excel esetén), hogy az ékezetes hosszú karaktereket aposztrófból meg a kutyatudja miből rakta össze. Ez le is bukott egyből backspace esetén, mert egy hosszú “ó” törlése két lépés volt. Először az aposztróf, utána maga a rövid “o”.
Miként “vizsgáljam” a pdf-et? Mit kellene benne keresnem, néznem? …vagy hogyan szedjem szét, milyen alkalmazással?
ps. Azon filóztam, ha nyomtatás előtt “legörbítené” az adott oldalon található szöveget és ezt követően küldené nyomtatásra, akkor tuti jó lenne.
Jah… elfelejtettem mondani. Csak az első oldallal csinálja ezt. Az első oldalt/borítót a kormányzati oldal generálja, az összes többit mi adjuk meg XML-ben (és ezen oldalakon nincs is hiba a karakterekkel).
Tudom még szűkíteni a hibajelenség lehetséges forrását.
Amit korábban töltöttem fel xml-t (Mojave alól, safarival) a kormányzati oldalra, az abból kreált pdf-et megnyitva, szerkesztés után JÓL jelenik meg és jól is nyomtatja. Amióta Big Sur (safari) alól töltöttem fel, az viszont már hibás.
Mindkét OS a legfrissebb összetevőkkel, biztonsági frissítésekkel rendelkezett/ik.
Az xml-t windows generálja. Az tökéletesen ugyanaz mint korábban.
Kíváncsiságból kipróbáltam chrome alól feltölteni, magyar lokalizációt állítva a SysPref-ben a chrome-nak. De ugyanaz a jelenség.
A pdf-be beletöltött fontok kódlapjai nem mindig okésak minden szoftver számára, maga az adobe is gyökér módon kezeli pl. indesign exportnál is, nem részletezném, ennek ellenére szerkesztésre még mindig az acrobat a kisebb szívás sztem, ha nem szereted, akkor még midig megoldható, hogy a másban editált pdf-ben 1 kattintással legörbíted a fontokat. Már persze ha nem omlik össze. :)
Hát ez nem egy kattintás :) … de én a DC megszokatlan hülyeségei miatt XI-t használok, abban pedig nincs benne (a vízjel – flatten kerülőutat használom).
Persze, de a plugin/framework nélkül nem hinném, hogy menni fog, ezt onnan tudom, hogy én annyira gyűlöltem kezdetben a dc-t, hogy még azokat is átmásolgattam, de persze az adobe már más formátumot használ. Vagy én voltam béna :) küldj privátban mail címet és átküldöm.
Végül visszakerült a Mojave… Default tökéletesen teszi dolgát nyomtatáskor és “szerkesztéskor” a pdf doksik esetén. Sem kedvem, sem időm arra hogy egy rendszerszintű elb@%&sra keresgéljem a megoldást különböző időpotsékoló (“ts”–mert a cenzúra szerint cs-vel vulgáris kifejezés) kerülőutakkal.
(Bár azt még nem tudom mi lesz gépcsere esetén…)
En 99.99999%-ban biztos vagyok benne, hogy a jelenlegi jo mukodesed egy bug kovetkezmenye, ami meg lett csinalva, illetve szabvanyos mukodesre lett cserelve kesobb. Es nem az ujabb rendszerek a hibasak, hanem a file aminel meg kene nezned, hogy mi lehet a baj es kitalalni valamit a javitasra. Mondunk mar egy csomo peldat, ami elofordulhat ezzel az allomannyal.
Nem hinném, hogy “bug” lett volna korábban a normális működés. Szemben azzal ha a file megnyitásakor JÓL jeleníti meg az adott állományt majd nyomtatásra küldéskor vagy egy minimális szerkesztéskor már nem csak a karakterek hiánya miatt de a betűtípus változásából is láthatóan hibázik. A fenti gondolatmeneted elsőre el is fogadnám, ha már simán megnyitáskor is “hibásan” jelenítené meg.
Próbáltam “dedikált” alkalmazásokkal csak simán a nyomtatást (friss printer driverrel, régivel…), de a hibajelenség ugyanaz. Az meg számomra nem járható, hogy napi 1-2 órát egerésszek még különböző app-okkal meg kerülőutakkal a több éve (és több generációnyi OS-el) megfelelően működő dologgal.
Javaslatok alapján nézegettem a forrásállományt (amennyire tudásom és lehetőségeim engedték). Az illustrator kifogástalanul kezelte /nyitás/mentés…stb (de ez számomra nem megoldás – főként ha 50-100 dokumentumot kell kezelnem). Akkor azt gyaníthatom, hogy nem a forrásállománnyal van konkrét probléma.
Továbbá sem gyanítom, hogy az eredeti állományban lenne a konkrét hiba – ha egyszer a pdf-ből kimásolva a szöveget hibátlanul jeleníti meg bármilyen szövegszerkesztő, böngésző-címsor, telefonkontakt névmező…stb. Semmilyen alkalmazás nem sikít hogy gond lenne a beágyazott szöveggel, karakterrel, betűtípussal.
Talán olyasmi lehet, hogy az adott font – a különböző források miatt – többféle kódolással van jelen a dokumentumban, és a Preview adott változata nem kezeli jól ezt a mentésnél?
Siman lehetnek helyettesiteses szabalyok is. Mittomen bele van agyazva egy font, aminel meg van adva, hogy milyen regio/kodlap zonakat tartalmaz, az eredeti szovegben pedig benn van egy helyettesites az ekezetes betukre. Amikor a preview elmenti, o aszerint menti el, ami elvileg benne van a fontban, de lehet hogy megsincs benne. Pl. “szepfont” van benne, es jelezve van, hogy unicode a font. De az eredeti szoveg a CE fontok helyeirol veszi az ekezetes karaktereket (ami a helyettesitesi ruleokban rogzitve van), amit pl a preview helyesen eltuntet, hiszen miert legyen egy elavult metodka szerint, ha tamogatott az unicode is? Aztan kiderul, hogy a fontba megsincsenek az unicode helyeken valodi karakterek?
De unicode eseten akar “repulo ekezet” is lehet a dologban, marmint a ‘font’, ami benne van unicode-nak van mondva, a szovegben pedig pl nem az ‘á’ karakter van, hanem ‘a’ es egy COMBINING ACUTE ACCENT karakter, ami igy kirakja az a’-t (masolva ebbol aztan kijohet ‘á’ is de a kombinalt betu is, amig az ember nem nezi meg jobban a byteszekvenciat, addig nem fog kiderlni, hogy mi es hogyan van benne). Az unicode egyszerusitesi szabalyok miatt, ha pl a preview ezt ‘á’-ra csereli, az megint csak az elvart mukodes. Viszont lehet, hogy a beagyaszott fontban hianyzik az ‘á’ betu. Stb. stb.
Szerintem nem fogjuk soha megtudni, hogy mi a baj az eredeti allomannyal.
Bármi lehet. De mivel korábban már tapasztaltam (máshol) ilyen helyettesítési anomáliákat így erre megpróbáltam külön figyelni. De erre ezesetben nem találtam “bizonyítékot”.
Egyébként egyszerű Arial betűtípusról van szó. Tudom… ez sem egyszerű a kódlapok miatt, bár ahogy néztem a korábbi OS-ekben szereplő Arial családot, az pont ugyanaz mint ami a BS alatt is van – mikor ez nyilvánvalóvá vált számomra, nem is foglalkoztam tovább a rendszerfontok piszkálásával. Byte-sequence-hez meg h@lye vagyok :-)
Ha érdekel / kíváncsi vagy, át tudok küldeni egy ilyen nyers pdf-et.
