Sondaj despre diactritice: utilizarea și afișarea corectă a acestora
Este un subiect despre care și eu am mai scris. Este vorba despre afișarea și utilizarea corectă a diactiticelor românești pe internet, în special în cazul șiterelor șȘ și țȚ, care trebuie să fie comma below (cu virgulă sub literă) nu cu cedillă, adică nu așa: ş Ş ţ Ţ. Momentan sistemele de operare moderne afișează corect aceste simboluri (Windows Vista, Windows 7, Mac OS X, distribuții recente de Linux). Sistemele de operare mai vechi dar cu o mare răspândire (e cazul Windows XP, care deși are 9 ani de la lansare este încă foarte răspândit) nu folosec corect diacriticile decât după un anumit update (EEupdate) care trebuie aplicat.
Moongate face un sondaj (eu amaflat de la Zoso.ro despre acest sondaj) legat de afișarea corectă a diacriticelor.
Fonturi cu suport pentru limba română – mic ghid practic
Acest articol a fost publicat și în revista Print Magazin, nr.5 – august 2009. Din păcate, în ediția online editorul nu a ilustrat suficient articolul motiv pentru care îl postez integral mai jos.
Datorită multitudinii de soluții de navigare pe web și a configurațiilor diferite ale acestora nu garantez afișarea corectă a unor simboluri grafice din acest articol. Din acest motiv, la sfârșitul articolului există un link de download ca document PDF.
Folosirea simbolurilor specifice limbii române (a diacriticelor) a dat (și mai dă, încă) multă bătaie de cap tehnoredactorilor dar și tuturor celorlați utilizatori de calculatoare personale care culeg/utilizează un text în limba română și cu diacritice. Situația se poate complica la migrarea documentului între diferite platforme: Apple Mac OS X, Microsoft Windows, Linux.
„Nu există fonturi românești ci doar fonturi Unicode în care sunt sau nu prezente caracterele specifice limbii române” afirmă, pe bună dreptate, dl. Cristian Secară.
Lipsa de standardizare la începutul erei digitale alături de neimplicarea Academiei Române în acest domeniu dar și lipsa suportului pentru internaționalizare din partea producătorilor de sisteme de operare și de produse software pentru procesarea textului și paginare a dus la implementarea unor soluții neortodoxe la utilizarea diacriticelor românești. Nu le voi mai aminti pentru a nu crea și mai multă confuzie dar și pentru că sistemele de operare moderne, respectiv versiunile actuale al programelor pentru procesarea textului și paginare includ deja suportul Unicode pentru afișarea simbolurilor specifice mai multor limbi. Atrag doar atenția asupra faptului că în trecut fonturile au fost „românizate” într-un mod barbar prin simpla înlocuire a unor simboluri mai puțin folosite cu cele românești. Astfel simboluri ca [ { } ] \ | ` ~ ‘ ” au fost înlocuite ă Ă Î î â Â ț Ț ș Ș. Una din consecințele utilizării acestei metode de localizare este și incapacitatea de funcționare a modulelor Hyphenation și Spelling din programele utilizate pentru că, indiferent de fontul utilizat, aceste module „citeau” simbolurile originale din font și nu semnele cu care acestea au fost înlocuite.
Spre sfârșitul anilor ’90 s-a introdus standardizarea actuală Unicode. În anul 2003 și Academia Română și-a exprimat punctul de vedere legat de simbolurile grafice cu care sunt reprezentate diacriticile românești. Dacă pentru aspectul literelor ă Ă î Î â Â nu au existat probleme, cu totul altfel era situația pentru ș Ș ț Ț. Simbolurile folosite inițial au fost ş (s cu sedilă), Ş (S cu sedilă) ţ (t cu sedilă) Ţ (T cu sedilă). La momentul în care Institutul de Lingvistică al Academiei Române a precizat clar, iar ASRO (Asociația de Standardizare din România) a standardizat utilizarea diacriticelor cu virgulă (comma bellow) în circulație se afla standardul ISO 8859-2 Latin 2 (Central and Eastern Europe) suportat și de Microsoft în sistemele sale de operare (cu mici modificări rezultând codificarea proprietară CP1250). Comisia ISO a fost informată de către ASRO de utilizarea incorectă a diacriticelor și a aprobat în 1998 versiunea revizuită a ISO 8859-2. ASRO a pus la punct standardul românesc SR 13411 care a stat la baza ISO 8859-16 Latin 10 cu suport intregral și corect lingvistic pentru limba română. Numai că această ultimă codificare este rar întâlnită.
În tabelele ISO, resprectiv Unicode, fiecărui simbol (caracter) îi corespunde un cod specific. Din dorința de a ușura standardizarea, divizia Typography a companiei Adobe (care produce multe din fonturile de pe piață) a înlocuit pur și simplu simbolurile şŞţŢ din ISO 8859-2 cu șȘțȚ. Acest lucru a mărit confuzia și a dus la incompatibilități (de parcă nu erau destule) între fonturi, sistemele de operare și soft-urile utilizate.
În prezent situația tinde spre normalitate deși acest lucru are loc cu un conservatorism ce poate fi explicat doar de utilizarea (încă!) a fonturilor localizate nestandard. Apple a suportat parțial (compatibilitatea era dată și de aplicații nu numai de sistemul de operare) standardul Unicode încă din Mac OS 8.x, iar de la Mac OS X 10.2 suportul este integral, alături de utilizarea tastaturii românești. Tot începând cu Mac OS 10.2 sunt utilizate corect caracterele șȘțȚ (pentru compatibilitate sunt prezente și şŞţŢ). Microsoft nu utilizează nici la Windows XP simbolurile corecte șȘțȚ ci doar pe cele vechi, şŞţŢ. Soluția este aplicarea European Union Expansion Font Update. Windows Vista și Windows 7 nu au această problemă. De asemenea, cele mai multe distribuții Linux utilizează corect și fără probleme diacriticile românești. În ce privește programele de paginare utilizate în DTP, QuarkXpress începând cu versiunea 7 și InDesgin începând cu versiunea 3 (prima versiune a Adobe Creative Suite) includ suportul Unicode.
Tabel: codurile Unicode și abrevierile specifice diacriticilor limbii române
| Simbol | Cod Unicode | Abreviere | Descriere | Subset |
| Ă |
0102 |
Abreve |
Latin capital letter A with breve accent |
Latin Extended-A |
| ă |
0103 |
abreve |
Latin small letter a with breve accent |
Latin Extended-A |
| Â |
00C2 |
Acircumflex |
Latin capital letter A with circumflex accent |
C1 controls and Latin-1 supplement |
| â |
00E2 |
acircumflex |
Latin small letter a with circumflex accent |
C1 controls and Latin-1 supplement |
| Î |
00CE |
Icircumflex |
Latin capital letter I with circumflex accent |
C1 controls and Latin-1 supplement |
| î |
00EE |
icircumflex |
Latin small letter i with circumflex accent |
C1 controls and Latin-1 supplement |
| Ș |
0218 |
Scommaaccent |
Latin capital letter S with comma bellow |
Latin Extended-B |
| ș |
0219 |
scommaaccent |
Latin small letter s with comma bellow |
Latin Extended-B |
| Ț |
021A |
uni021A |
Latin capital letter T with comma bellow |
Latin Extended-B |
| ț |
021B |
uni021B |
Latin small letter t with comma bellow |
Latin Extended-B |
| Ş |
015E |
Scedilla |
Latin capital letter S with cedilla |
Latin Extended-A |
| ş |
015F |
scedilla |
Latin small letter s with cedilla |
Latin Extended-A |
| Ţ |
0162 |
uni0162 |
Latin capital letter T with cedilla |
Latin Extended-A |
| ţ |
0163 |
uni0162 |
Latin small letter t with cedilla |
Latin Extended-A |
Atenție: utilizarea și modificarea unui font sunt limitate de producător prin copyright. Nu modificați fonturi fără acceptul scris a deținătorului drepturilor asupra fonturilor.
Doar pentru exemplificare prezint modul corect în care un font se poate localiza corect pentru utilizarea în limba română. Am utilizat în acest scop versiunea DEMO a programului FontLab 4.6 și fontul FreeSans aflat sub licență GPL.
Se deschide fontul in aplicaţia FontLab și se setează modul de afișare Unicode / Pages, iar din lista cu seturi de codificare (Encodings) se alege MacOS Romanian. Se apelează Font Info… din meniul File. Se fac setările din imaginile următoare:
 |
 |
 |
După alegerea numelui apăsați în ordine: Build style name și apoi Build Names.
 |
Click pe Build OpenType Names.
 |
Click pe Import names, apoi din lista Language alegeți 37 Romanian sau scrieți 37 Romanian dacă lipsește din listă.
Se salvează setările apăsând pe OK. La numele fontului alegeți un nume descriptiv dar unic (atenție și la familiile de fonturi) și eventual adăugați particula CE la sfârșit. Localizați în font codurile unicode specifice diacriticelor. În cazul în care un simbol lipsește FontLab îl va afișa gri. Cu dublu-click sunt aduse automat simbolurile necesare. În cazul în care este nevoie, localizați simbolul comma (virgula) și plasați-l prin Copy/Paste sub una din literele comma bellow: s (0219), S (0218), t (021B) sau T (021A). Dimensionați virgula și poziționați-o central sub simbol. Apoi cu Copy/Paste plasați-o sub celelate trei simboluri comma bellow rămase. Eventual reajustați orizontal poziția virgulei sub fiecare din aceste diacritice. Treceți, acum, encoding din MacOS Romanian pe MS Windows 1250 Central European. Copiați simbolul Ș de la 0218 la 015E, ș de la 0219 la 015F, Ț de la 021A la 0162 și ț de la 021B la 0163.
|
|
În final salvați noul font cu comanda Generate font… din meniul File. Alegeți (recomandabil) același nume de fișer cu numele fontului (fără spații însă) și nu uitați de particula CE. Ca format de export optați pentru OpenType (*.otf), iar fontul va funcționa astfel pe toate platformele software cu suport Unicode. |
Bibliografie:
- pagina web a dl. Cristian Secară;
- Asociația de Standardizare din România;
- secțiunea .RO a forumului MacUser.ro;
- GNU FreeFont;
- ISO (International Organization for Standardization);
Aplicația FontLab a rulat pe o mașină virtuală Wine pe sistemul de operare Linux Ubuntu 9.04, iar capturile de ecran au fost realizate cu aplicația Take Screenshot. Rezultatul modificărilor prezentate nu a fost salvat iar fontul nu a fost modificat.
Freelancer
După tot balamucul din ultimile luni (unu, doi, trei, patru) am decis să merg pe cont propriu. Mă lansez ca freelancer în domeniiile DTP / PrePress / Color Management. Detalii pe pagina asta.
InDesign: Print sau Export PDF?
Încă de la prima versiune Adobe InDesign a importat și exportat nativ documente PDF, fără a avea nevoie de extensii. Dacă în ce privește importul documentelor PDF totul e simplu, la fel ar trebui să fie și exportul.
Am putea afirma că și exportul către formatul PDF este simplu, și nu avem cum să contrazicem asta. Într-adevăr, avem la dispoziție în meniul File – Export layout as PDF… În fereastra de dialog putem alege un preset din cele oferite standard sau, mai nou pentru că și Adobe Acrobat Distiller se intregrează foarte bine în pachetul Adobe Creative Suite 4, putem alege unul din preset-urile (joboptions) disponibile în Distiller sau putem alege un preset specific InDesign. În plus, se pot configura și alți parametri ai exportului. De altfel, aceasta este metoda pe care Adobe o încurajează la obținerea PDF-urilor, indiferent de destinația documentului (print, web, arhivare etc.). În cazul în care PDF-ul exportat are versiunea 1.4 (Acrobat 5) sau mai mare, în documentul rezultat se vor menține toate atributele obiectelor din layout-ul original: vectori, texte, transparențe, culori spot, layer-e etc., iar acest lucru este nu poate fi decât de apreciat.
A doua metodă de obținere a PDF-ului este cea clasică, prin dialogul Print. Și aici există două variante: cea utilizând din lista de imprimante pe cea instalată odată cu Adobe Acrobat și anume Adobe PDF, sau varianta PostScript File în care obținem un document PostScript pe care apoi îl distilăm. Singura diferență între aceste variante este numărul pașilor ce trebuie parcurși până la obținerea PDF-ului, altfel rezultatul este identic (cu condiția configurării corecte a imprimantei virtuale Adobe PDF).
Acum vine întrebarea: care metodă (Export sau Print) să o folosim pentru obținerea PDF-urilor? Recomandarea venită de la Adobe este utilizarea opțiunii de export. Recomandarea autorului este… oricare! Este o opțiune personală, dar, mare atenție: dacă PDF-ul este destinat tipăririi printr-o tehnologie oarecare pot să apară mici chestiuni de compatibilitate. Deși vizual ambele metode produc același rezultat, în structura lor PDF-urile rezultate sunt diferite. Cele mai multe RIP-uri sau echipamente care procesează documente PDF în vederea tipăririi acceptă versiunea PDF 1.4 (Acrobat 5) sau chiar mai mare dar nu neapărat suportă toate capabilitățile versiunilor mai recente. În cazul în care s-a utilizat metoda exportului, iar rezultatul procesării PDF-ului nu este cel așteptat atunci soluția este obținerea unui PDF prin opțiunea Print. Diferența structurală între PDF-urile produse prin cele două metode este că în cazul printării către un fișier PostScript care apoi este distilat (același lucru are loc și la utilizarea imprimantei virtuale Adobe PDF) documentul este aplatizat (flatten) prin rasterizarea efectelor și a obiectelor complexe din documentul sursă InDesign. Autorul recomandă utilizarea PostScript© 3 care aduce o bună reproductibilitate în PDF a documentului sursă față de Level 2 care nu acceptă obiecte foarte complexe.
În concluzie, indiferent de cum a fost obținut documentul PDF, verificați rezultatul procesării acestuia mai ales la utilizarea unor obiecte și efecte de complexitate ridicată. Nu este nimic greșit la utilizarea metodei export. Au loc mai puține transformări (InDesign -> PDF, este o metodă rapidă iar rezultatul este perfect. Versiunile moderne ale RIP-urilor (Prinergy, Harlequin > 6 etc.) au intregrat InRIP Flattening și pot procesa aceste PDF-uri fără cusur. Metoda Print & Distill deși are mai multe conversii (InDesign -> PostScript -> PDF), respectiv mai mulți pași consumatori de timp și resurse, produce PDF-uri utilizabile și în RIP-uri mai puțin recente. De asemenea este singura metodă de a produce un PDF dintr-un InDesign Book (colecție de documente InDesign ce fac parte din aceeași lucrare: revistă, carte etc.).
Articol publicat și în revista Print Magazin, nr.4 din 2009.
Mit și adevăr în industria de PrePress
De-a lungul timpului noi tehnologii au făcut mai facilă pregătirea diverselor documente în vederea tipăririi, dar, ca multe alte lucrui noi, acestea au adus și mai multe sau mai puține bătăi de cap. Fiecare produs nou (fie că e vorba de un produs software fie că e vorba de un echipament fizic) a adus noi facilități, dând frâu liber creativității dar din păcate la fiecare nouă versiune existau și bug-uri sau diverse limitări tehnice în ce privește reproducerea diverselor efecte în tipar.
Sunt convins că veteranii din domeniu își amintesc de situații dificile ca de exemplu franjurarea unor elemente vectoriale sub un bitmap cu transparență, dificultatea reproducerii unor elemente cu culori speciale situate sub obiecte cu transparență, reproducerea în trepte a gradienților, artefacte cauzate de compresia imaginilor, portarea documentelor sau numai a fonturilor de pe o platformă pe alta, probleme cu localizarea fonturilor (diacritice) și multe altele.
Voi încerca enumerarea câtorva dintre aceste situații, majoritatea din trecut, evidențiind workaround-ul de atunci și dacă, în prezent, aceasta mai constituie sau nu o problemă.
Fonturile Postscript sunt cele bune, iar fonturile TrueType sunt rele
Fontul Postscript (Type 1) era constituit din două părți: Screen font sau Bitmap font utilizată strict la afișarea pe ecran și Outline font sau Printer font utilizată la reproducerea pe un dispozitiv capabil de Postscript. Acum circa 10 ani, managerul de fonturi preferat era ATM (Adobe Type Manager) Deluxe. Acesta instala pe platforma Windows și suportul pentru fonturi de acest tip în timp ce Mac OS 7-9 suporta nativ aceste fonturi, ATM folosind doar la gruparea și activarea/dezactivarea fonturilor. Fontul era concretizat în două fișiere (*.pfb – fontul de ecran și *.pfa – fontul de imprimantă). Absența părții de imprimantă aducea cu sine înlocuirea cu Courier, dar acest lucru se putea observa doar la imprimare. Atât timp cât exista particula bitmap a fontului acesta putea fi utilizat pe ecran și nimic nu avertiza asupra problemelor de la imprimare. Mai mult, puteau fi folosite doar anumite mărimi ale caracterelor, cele implementate în font.
Fontul TrueType a dorit să elimine toate aceste probleme, utilizând atât pentru afișarea pe ecran cât și pentru imprimare fonturi vectoriale. Tehnologia dezvoltată în comun de Apple și Microsoft avea să fie implementată diferit, însă, pe fiecare platformă. Asta a dus la incompatibilități cross-platform dar în cadrul unei platforme reproductibilitatea rezultatelor era bună. Tehnologia TrueType (în implementarea Microsoft) a fost rapid adoptată și în alte sisteme de operare devenind un standard de facto și a permis ulterior localizarea fonturilor (adăugarea diacriticelor și a altor simboluri specifice fiecărei limbi) în limita a 255 de simboluri (caractere) pe font.
Concluzie: mitul este neconfirmat dar treptat fonturile Type 1 au dispărut din industrie. Rar mai găsești vreun astfel de font pe sistemele actuale. Sistemele de operare moderne suportă tehnologia TrueType toate extensiile sale și urmașa acesteia, OpenType. Ba mai mult Apple preferă începând cu MacOS X (fără a renunța la compatibilitate) fomatul *.ttf față de propria implementare mai veche *.dfont. TrueType și OpenType asigură rezultatul dorit având și avantajul suportului pentru mai multe alfabete naționale.
Utilizarea fonturilor „system” duce la rezultate dezastruoase
Orice sistem de operare include un set minim de fonturi, acestea incluzând în general familiile Arial, Courier, Helvetica, Impact, Lucida, Tahoma, Times (Apple) sau Times New Roman (celelalte sisteme de operare), Trebuchet și Verdana. Pot exista confuzii între fonturi cu nume similar (Times – TimesNewRoman). De asemenea, pot apare probleme când pe un sistem se aduc fonturi cu nume identic dar de tehnologii diferite (TrueType și OpenType).
Concluzie: mitul este parțial confirmat. O atenție mărită la colectarea fonturilor împreună cu lucrarea și activarea doar a fontului necesar înseamnă obținerea rezultatului dorit. Personal am constatat că se poate utiliza un font OpenType în locul unuia TrueType cu același nume, dar nu și invers. Constatarea este valabilă doar când ambele fonturi folosesc același code-page, compatibilitatea dispărând în cazul fontrilor românizate fără a respecta codificarea standardizată.
Orice font poate fi localizat
Există multe produse software pentru crearea, editarea și conversia fonturilor. Pot enumera: FontLab (un produs cross-platform excelent, adus la zi în ce privința tehnologiilor fonturilor și a standardizării localizării și compatibil cu majoritatea arhitecturilor de fonturi) și Fontographer (un produs încă bun, dar care nu a mai fost dezvoltat de câțiva ani și nu mai este la zi). În anii ’90 majoritatea fonturilor includeau doar alfabetul latin standard (code page ISO 8859-1) și a apărut necesitatea introducerii în fonturi și a simbolurilor specifice fiecărei limbi. Deși a existat întotdeauna o standardizare (ISO 8859 și apoi Unicode) lipsa documentării dar și lipsa suportului din partea sistemelor de operare pentru setul extins de caractere a dus la metode neortodoxe de românizare a fonturilor prin înlocuirea unor simboluri mai puțin sau deloc utilizate. De asemenea neimplicarea totală până prin 2006 a Academiei Române în ce privește aspectul diacriticelor românești a generat apariția a tot felul de variante a acestora.
Începând cu sistemele de operare lansate în ultimii doi ani (Windows Vista, Mac OS X 10.5, versiunile recente de Linux) dar și în Windows XP cu Eastern Europe Update aplicat suportul pentru limba română este integral. Mai mult, sunt suportate noile caractere Șș și Țț (comma below – cu virgulă) față de cele cu sedilă utilizate în trecut.
Concluzie: mitul este un fals pentru că nu putem numi localizare înlocuirea unor caractere cu cele specifice limbii române. De asemenea, utilizarea unor fonturi nestandard aduce după sine funcționarea incoerentă a modulelor de despărțire în silabe din programele moderne de layout.
Formatul EPS este de preferat în locul altora
La începutul erei digitale în tehnoredactare și pregătirea tiparului existau multe limitări tehnice la aplicarea unor efecte considerate azi banale. Una din ele era posibilitatea decupării și afișării doar a unei porțiuni dintr-o imagine raster. Se rezolva prin desenarea unei curbe închise (path) în Photoshop și setarea acesteia ca cliping path. Numai că programele de layout din trecut (QuarkExpress și PageMaker puteau face acest lucru doar dacă imaginea respectivă era în format EPS (Encapsulated PostScript). Adevărul este că acele programe nu făceau nimic, doar copiau codul Postscript din fișierul imaginii EPS (inclusiv conturul de decupare) în output-ul acestora (un document Postscript conținând layout-ul). Toată treaba era făcută defapt de Photoshop și de procesorul final al documentului (RIP sau Acrobat Distiller).
Concluzie: mitul este infirmat. Singurele atuuri reale ale formatului EPS erau, în trecut, prezența elementelor vectoriale, cliping path și posibilitatea de a utiliza culori spot. În orice altă situație formatul EPS aducea dificultatea procesării documentelor prin output-ul consumator de spațiu pe disc, prin compresia JPEG ce putea fi utilizată opțional, prin riscul adus de înlocuirea fonturilor în elementele text conținute sau prin cele două variante în care există formatul, ASCII sau binar. Toate acestea pălesc azi în fața formatelor TIFF (Tagged Image File Format) ce a devenit standard industrial adoptat și de ISO și PSD (PhotoShop Document) extrem de flexibil și de dotat în facilități.
Articol publicat și în revista Print Magazin, nr.3 din 2009.
Publicitate
Scriu în
