Nem ertelek. A fentebb is emlegetett “PT Sans” rendszerfont, egyike azoknak, akik a cyrill zonahoz adnak glypheket.
Igen, de a Font Book engedte kikapcsolni, tehát nem nélkülözhetetlen, cirillül nem írok, és Pí nincs is benne, mint kiderült.
Úgy emlékszem csak új liszenszet nem tudsz venni, de ha már van neked, akkor működik.
Másrészről van még több lehetőség is. Typeface, Rightfont …
Rendszerfontok:
Nem kívánok erről vitatkozni, ezt egyszerűen nem is értem miért kellene kikapcsolni azokat, hisz ezek a rendszer részei és szükséged lehet rá. Amennyiben Te így látod jónak, legyen.
Harmadrészt, ha van időd és energiád, akkor elkészítheted a saját unicode táblás betűtípusaidat. Ezzel talán tudod csökkenteni a rendszerfontok számát.
A Glyphs, Fontlab 8 a megoldás erre. További segítséget nyújt a UnicodeChecker
1 kedvelés
Különbséget tennék (és teszek) a rendszerfontok és a rendszertelepítő által felrakott fontok között: a Catalina “System/Library/Fonts” mappában 90, a “Supplemental” mappában 243 font(család) van, valóban szükség lenne ennyire? Pl. 12-féle Hiragano-családra? Régebben a rendszer 10–20–30 fontcsaláddal elvolt.
Mojavén a “Supplemental” mappa nem létezett, a “Library/Fonts” mappában volt a “Supplemental” mappa tartalmának kb. FELE.
Font Bookal is lehet csoportokat létrehozni stb., igazából nincs szükségem “profi” fontkezelőre.
A Pí-probléma más jellegű, csak éppen kiderült, hogy nem a kikapcsolt font miatt.
De ilyen is van (volt régebben is), tán a böngésző helyettesítő fontjával kellene kísérletezni:
Ertem az alapveto, kiindulasi “hisztit”. Hasonlo teruleten tevekenykedokent engem is ertetlenkedve erint a sok szemet, hogy latszolag feleslegesen novekszik az a font directory.
Bar teny, hogy a kulonbozo uj glyph-ek, emoji-k…stb. nem egy “kozponti raktarbol” erkeznek, hanem a kulonbozo addOn-okbol. Lehet epp az altalad emlegetett “Hirogano” csalad egyik elemeben van egy olyan glyph amit masnal nem talalsz meg - viszont hasznalatos.
Ezekre a sz@rokra is ugyanolyan licence opciok ervenyesek mint mondjuk a Helvetica font publikus hasznalatara.
Gondoljunk csak a peldaerteku pantone book eltunesere az adobe cuccokbol. (ez eltunt mar? …nem nagyon kovetem az adobe hulyesegeit mostansag)
Ez a disqus-os sząrsag meg szerintem szimplan kodolasi, vagy szerver oldali baromsag.
1 kedvelés
Ahogy en latom, mindenki fel akarja talalni a spanyol viaszt. De velemenyem szerint rohadtul nem ezt kene csinalni. Szuper es suvegelendo dolog a kreativitas, de amikor mar iparagakat szakitanak darabokra a sok feleslegesen kitalalt sztenderddel - semmi ertelme. Eljutottunk oda, hogy ket azonos teruleten dolgozo alkalmazas nem kepes olvasni egymas termeket. Agyrem.
Egy ISO-itas raferne a technologiakra. 
Ertem ezalatt: Egy barmilyen gepen, barmilyen alkalmazassal generalt jpg filet meg tudok nyitni barhol… tovabb is szerkeszthetem (ok, leegyszerusitettem).
De ott van a mar emlegetett RTF formatum es a tobbi “kisajatitott” file formatumrol ne is beszeljunk (psd, ai…stb).
Jo lenne vegre definialni hogy egy-egy fileformatum milyen “kontener” tulajdonsagokkal rendelkezzen es mit lehet tenni vele. Ezek a tulajdonsagok barmilyen rendszeren, barmilyen ilyen fileformatum kezelesre alkalmas szoftver/alkalmazas kepes legyen zokkenomentesen modositani, megjeleniteni stb.
Igaz, ezzel ki lenne huzva a szek pl. az Adobe alol. De legalabb vegre elindulna egy valos verseny, hogy ki kepes ugyanarra az alapra jobban hasznalhato es jobban mukodo alkalmazast irni.
Huhhh… nagyon elkalandoztam
PS.: tegyuk le egy uj technologai revolucio alapjait! Hozzunk esszeru valtozast a tech vilagaba
1 kedvelés
Az megvan, hogy a JPG mellett, van masik 300 kepformatum? Kezdve a bmp/tiff/gif/pcx/png csapattal (csakhogy a tobbi 20+ eves cuccot emlitsem)? Ezek pont nem voltak kivalthatoak egymassal, mert mindegyik olyan featuret implementalt, ami a masikban nem volt! Tehat, barmennyire is szeretnel, nem tudsz univerzalis formatumot kitalalni. Hiaba ISO szabvany peldaul az MP4/MOV kontenere, a codecekkel akkor is “para” lesz. Ha pedig betonba ontod a codeceket, hogyan lesznek ujak kitalalva? A szabvanyos peldanal maradva, a HEIC, amit az iPhone fotoz, ha szabvanyok iranyabol kozelited, egy totalisan szabvanyos formatum. ISO standard konetenrben van egy ISO standard codeccel tomoritett adathalom. Megsem tudod azt allitani, hogy mindenhol meg tudod nyitni. De ugyonigy hozhato peldanak a JPEG 2000 is, ugyonannak az ISO szabvaynak egy ujabb kiadasa, ami az eredeti JPEG, viszont ezt a verziot, kozel sem tudod olyan szeleskorben megnyitni, eloallitani, szerkeszteni.
Persze! Csak ezt ragadtam ki szemleltetesnek. Ok, hogy a tobbi kepformatumnak megvannak a maguk tulajdonsagaik, de ettol fuggetlen kepet jelenitenek meg (alpha-val, mozgassal…stb)
Ilyen aspektusban azt mondhatjuk, hogy a gif szinte mindenre jó lenne (egy kis turbozassal).
De effektív a fejlodes sem lenne korlatozva. Egszeruen az adott formatum lenne frissitve az uj feature-el. De nem vagyok programozo, csak otletelek.
Dehat, erre irtma peldanak a JPEG 2000-t. Egy csomo dolog nem kezeli. Hiaba ugyonaz a szabvany (ujabb verzio, raadasul ISO), ettlol nem lesz univerzalis. De ugyonez van az AVI-val. Szeles kodektamogatassal rendelkezik, de nem ersz semmit ezzel, ha a masik szoftver pont azt a kodeket, megoldast nem ismeri.
Ott van szerencsetlen SVG. Megis tudsz eltero “dialektust” hasznalni es olyan dolgokat belerakni, amit az egyik szoftver ismer, a masik nem. Pedig ez nem egy .ai, hogy zart legyen es nagyon kuzdeni kelljen mar a megnyitasaval is.
NA, hat errol beszelek …ezt kellene rendbetenni. Ehelyett csak egyre tobb kiterjesztes/alkalmazas (amelyeknek egyebkent marhara semmi haszna) jelenik meg es egy ultra nagy kaosz belole. Ahelyett hogy leulne par ember es azzal foglalkozna, hogy ne legyenek olyan problemak amiket Te is emlitettel. Hogy az .avi .svg mukodjon ugy, ahogy kell neki. Amennyiben nem kepes az adott SW kezelni az adott kiterjesztest, akkor effektiv “megvonjak” a keszitotol az adott kiterjesztes hasznalatat. Igen, ez effektiv egy licence. Idonkent mar en is olyan kiterjesztesekkel talalkozom, hogy csak lesek mint pok a sarokban.
Dehat, az elobb, meg azon voltal kiakadva, hogy nem hasznal mindenki egy fajta formatumot 
Most meg megvonnad valakitol a formatum hasznalatat, mert a 8 eve abbahagyott fejlesztesu szoftverebe nem rakja bele a felhasznalt kontener legujabb valtozasait? Tenyleg xkcd gyanus ez
Igen, az egyikben van, emlékeim szerint 10.10–10.11 környékén tapasztaltam, ettől még a maradék 10 felesleges. Mikor is volt, amikor még lehetett választani a nyelvek közül telepítésnél? Talán soha?
(Helyesen: Hiragino)
A netet túrva nem egyedi a problémám.
Szóval egyszercsak (Mojave –> Catalina váltásnál) valaki kitalálta, hogy zúdítsuk a hülyékre ezt a katyvaszt…
“
Ventura Update: Deactivating supplemental system fonts is not possible anymore in macOS Ventura. It looks like Apple has disabled this functionality and prevents Typeface from deactivating any system fonts, including the Noto fonts. If you want to be able to deactivate system fonts to clean up font lists please let Apple know by sending your feedback.”
Itt a tudomány: Font Management in macOS
Ennyire nem dramatizaltam tul, lehet rosszul fogalmaztam. A masik oldalon viszont tenyleg “ertelmetlen”, hogy (pl.) a kepfileok azonositasara baromi sok kiterjesztest hasznal a vilag. Csak azert, mert az egyiknek van egy x tulajdonsaga, a masik kiterjesztesnek meg egy y tulajdonsaga. Ha le lenne kicsit szukitve ez a mennyiseg, viszont sokkal komolyabban vennek az adott kiterjesztesnek valo megfelelest akkor velhetoen nem lenne ekkora kaosz.
Ertem amit mondasz, hogy egy-egy ujabb W kiterjesztes rendelkezik X tulajdonsaggal. De siman fel lehetne vertezni a korabbi Y kiterjesztest az ujabb X tulajdonsag kezelesevel.
De mint mar hangsulyoztam. Csak filozofalok ezen.
De nem teheted meg, hogy mostantol a jpg kap 10 uj dolgot amitol lehet jobb lesz de a regi programok majd nem tudnak vele mit kezdeni. Az egyszeru user meg csak azt latja hogy sima jog-t nem tolt be a megszokott programja.
Valojaban ha van egy uj formatum es nem tudod mi az 1,5 masodperces google kereses megnezni mi az. Akinek meg ez nem megy valoszinuleg szuksege sincs ra 
Ez így tök logikus, nem?
A TIFF pl. ilyen, beleépült az átlátszóság, a rétegek és a JPG-tömörítés lehetősége stb.
Ja, ennek koszonheto az, hogy megvan ugyonaz a para, mint a JPEG-nel. Fogod a bevalt, 15 eve hasznalt szoftveredet, es hiaba ismer egy formatumot, megis belefuthatsz olyan fileba, amit nem tudsz megnyitni vele, pedig TIFF ez is es TIFF az is (megoldas: frissits szoftvert, vagy vedd meg ujra, vagy barmi mas). Vagy lehet, hogy meg tudja nyitni, de ertekelhetetlen lesz, mint a CYMK JPEG, ami sok helyen RGB-kent probal megjelenni (mert a szoftver nem lett updatelve, hogy kezelje a CMYK JPEG-et). De lehet venni peldanak az AVI-t is, ami tok jo univerzalis formatum volt (fejlecben definialt codecek, mind videora, mind audiora, igy codecek kellettek es meg lehetett nezni mindent), ami egy ideig jo otletnek is tunt, de aztan kiderult, hogy kellene nekunk variable bitrate/variable packet/stb, de az AVI fix szerkezete ezt pont nem tette lehetove, igy levaltasra kerult. Levaltani pedig azert kellett, mert az AVI egyik alapja, hogy adott meretu “szegmensekbol” epul fel. Azokhoz byte alapjan oda kell tudnod ugrani, es ezek a szegmensek minden esetben egy i-frame -vel fognak kezdodni. No ha ezt megvarialod, azon tul, ami varialhatosagot a 0. lepestol beleterveztek a formatumba, azzal azt ered el, hogy megleped a szoftvereket, amik nem ismerik ezt a kepesseget. Az ujakat nyilvan fel tudod kesziteni, hogy alapjaiban valtozott a formatum, de a regiek teljesen meg lesznek halva. Szoval, nem tehetjuk meg, hogy bebetonozunk adott celra valamit, mert ha kesobb csinalnank jobbat, akkor nem fogunk tudni jobbat csinalni. De ugyonezt el volt/van mar jatszva a zippel is. Szerintem ezt, nagyon nem kellene bebetonozni, mert minden egyes valtozasnak megvan az ertelme.
2 kedvelés
Aha.
(10)
Ok, teljesen jogosak az ervek.
De ez az inkompatibilitasi kaosz akkor sem egeszseges
Jobb lenne egy kompakt, atgondoltabb, modularisabb es szigorubban kezelt “szabvany”. Szerintem egy ilyen elkepzeles sokkal egyszerubbe (akar csekelyebb terjedelmuve) tenne a rendszereket is (nem kene tobb tucatnyi/szaz filekiterjesztest ugyanazon file/media tipusra ismero kodot beepiteni a rendszerbe).
Itt @Czo altal fel lett dobva a szoftverek frissitetlensegere vonatkozo megjegyzes. De ezesetben visszautalnek egy korabbi eszreveteledre, miszerint (a lenyegi reszt megragadva): “ha korlatok, szabalyok koze zarunk valamit, akkor ‘elveszik’ a kreativitas, a fejlodes”.
Ha az IT vilaga “elturi”, hogy a kulonbozo bongeszesi, vagy hasznalati statisztikai alapjan nem alkalmaznak egy frissitest, mert a stat alapjan meg mindig hasznalnak ozonviz elotti bongeszot, alkalmazast – akkor ez mi, ha nem a fejlodes akadalyozasa?
Az inkabb uzleti dontes. A brozer featuresetek megletet tudod ellenorizni JS oldalon, tehat ha van valami, akkor nyugodtan hasznalhatod, ha meg nincs valami, akkor fut az a kod, ami az adott feature “emulalasahoz” kell. Ahogyan 20 eve is csinaltuk a CSS animacioknal. Ha volt CSS animacio support, akkor azzal animaltuk (ez ugye HW gyorsitott volt), ha meg nem volt, akkor JS tekergette timerbol a css propertyt az animaciohoz. De ugyonezt csinaljak a jatekfejlesztok is, amikor levizsgaljak milyen DirectX feature setet tamogat a geped, es az annak megfeleloen megirt renderer/konfiguracio indul el.
Dehogynem kene beepiteni. Ha 2 .JPEG vagy 2 .TIFF nem egyforma szerkezetu, akkor is be kell epiteni az ujabb .JPEG/.TIFF-hez a tamogatast. Ha pedig be kell epiteni, akkor tok mind1, hogy az is .TIFF, lehetne akar .PAFF is. Ha mereven kell figyelni, hogy a friss csiliJPEG 14.2-es fileformatumot, tamogatja-e a jelenleg a gepemen levo szoftver, vagy csontrafagy/felrobban/eszrevehetetlenulbugzani fog, akkor inkabb ne hivjuk azt is .JPEG nek, hanme legyen .CSPG, es akkor kerek perec latom az ikonbol/duplakattintasbol/stb, hogy nincs hozza tamogatasom. Szerintem tok mind1, hogy csereljuk-e a kiterjesztest, vagy nem. Ha nem csereljuk, olyan kaosz lesz, mint az USB-C -nel, ahol 1 lyuk van elvileg/igazabol. Aztan megis elofordul, hogy van ketto, tok egyforma lyukkal rendelkezo eszkozod, aztan van egy kabeled, aminek mind a ket vegen olyan bizgentyu van, ami belemegy mind a ketto lyukba, aztan latszolag megsem tortenik semmi sem. Ez szerintem rosszabb, mint ami elotte volt. FW dugo - FW lyuk, ha be tudod dugni megy, ha nem tudod, nem megy. Persze, az se jo, amit az USB-IF csinal, az USB szamozasaval (gondolok itt az USB 3.1 Gen 1-re peldaul).
Ha vizsont elkezded opcionalissa teni az implementaciot, akkor pl siman kerulhetsz olyan helyzetbe, hogy hiaba kezeli pl. mind a ketto szoftver a .TTF formatumot, az egyik eseteben a raszterizalt szoveg sokkal szebb lesz, mint a masik eseteben, mert pl a masik, noha .TTF-rol van szo, nem figyeli/kezeli az opcionalis reszet, pl. a hintinget.
2 kedvelés
Tokre igazad van!
A jo megoldas mindenkepp az lenne, hogy komolyabb/szigorubb szabalyzast kellene eszkozolni ami nem enged kibuvot.
Ez jotekony hatassal lenne a teljesitmenyre es a kornyezetunkre (kevesebb technologiai szemet) is.
1 kedvelés