Sou a: Inici / El projecte / Nyaps / La cerca en PDF's. L'efecte sobre l'ela geminada

La cerca en PDF's. L'efecte sobre l'ela geminada

per Sebastià Vila-Marta darrera modificació 17/11/2012 22:31
Assaig sobre la consideració que han de tenir els documents PDF pel que fa a la cerca de documentació.

Introducció

Repetides vegades, especialment amb el Marc Antoni, que és un bon coneixedor del format PDF, hem tingut converses i discussions que tenen com a base la inconveniència de certes solucions a la tipografia de la ela geminada per que trenquen la possibilitat de cercar correctament en el PDF on s'han aplicat. Fa uns dies, Joan Montané de Softcatalà, en un correu privat incidia en el mateix aspecte. El Joan indicava que el paquet Babel del TeX, que defineix les macros \lgem i \Lgem per a escriure la ela geminada (l·l i L·L, respectivament) i, tot i que l'aspecte visual obtingut és molt bo, resulta que internament és un punt baix (.) i en cercar coses als PDF obtinguts... cal fer-ho amb el punt baix!!!.

Segons la meva opinió, aquest punt de vista és erroni i està fonamentat en una concepció esbiaixada del paper que juga un document PDF i de las seva estructura. En aquest document miraré d'argumentar aquest extrem. La intenció és que serveixi com a punt de partida per entendre millor la situació. La bona comprensió d'aquest fenomen de ben segur que ens ajuda  a copsar amb més profunditat la problemàtica entorn la ela geminada.

Argumentació

Caràcter, code point

D'acord amb Unicode, un caràcter és la unitat mínima de codificació d'un text que permet aplicar els tractaments necessaris al text. El que constitueix doncs un caràcter s'ha d'entendre com una representació abstracta de part d'un text que facilita els tractaments habituals d'aquest text (visualització, edició, cerca, etc.). Seguint aquesta idea un caràcter es defineix com la representació abstracta dels components més petits de l'escriptura que tenen valor semàntic.

Cada caràcter recollit per Unicode es representa per un nombre natural únic que anomenem code point.

És important fer notar que la concepció que un usuari té d'una caràcter no es correspon amb la concepció tècnica. Per a un usuari, per exemple, «à» pot ser vist com un caràcter, quan tècnicament poden ser perfectament dos caràcters.

Glif

D'altra banda,un glif és un objecte gràfic que correspon amb la representació sobre un medi físic (paper, etc) d'un o més caràcters. La relació entre caràcter i glif és clau en aquest document. Cal tenir present que:

  • A un caràcter li pot correspondre, fins i tot en el context d'una mateixa pòlissa, més d'un glif. Per exemple, podem tenir diferents formes per a una Q segons en quin context es trobi.
  • Un glif pot estar associat no a un caràcter sinó a una seqüència de caràcters. Aquest és el cas de la lligadura clàssica st, per exemple.
  • Diversos caràcters poden compartir un únic glif. Aquest és els cas, per exemple,  de «greek small letter mu» μ i «micro sign» µ, que en certs fonts poden correspondre al mateix glif.

Font

Un font és una col·lecció de glifs que conserven coherència de disseny. En un font els glifs estan xifrats. Com a conseqüència de la relació entre glifs i caràcters, generalment el xifrat d'un glif i dels caràcters que li corresponen no és el mateix. Un fitxer de fonts conserva, a més de glifs informació per associar un caràcter o seqüència de caràcters a un o més glifs.

Render

Un renderitzador és una aplicació (o part d'una aplicació) de processat de text que donat un text representat  com una seqüència de caràcters i un font (o més), obté una impressió del text, entesa com la realització física del text. En una impressió els diferents glifs no es disposen linealment sinó que es posicionen de forma adequada sobre el paper seguint la tradició d'escriptura escaient. L'exemple més senzill el trobem en la lletra «à», qiue pot representar-se com a dos caràcters, cadascun dels quals esdevé un glif i que acaben situant-se un damunt de l'altre. La tipografia matemàtica encara ofereix exemples molt més clars d'aquest principi. Els glifs que un renderer decideix usar per «dibuixar» una impressió res tenen a veure amb els caràcters sinó amb l'aspecte visual que es vol obtenir per representar aquests caràcters sobre paper.

Des d'aquest punt de vista, el fet que Babel decideix dibuixar el punt volat amb un glif o un altre no és en cap cas un error. Ho seria només si el resultat, la impressió, no fos correcta. Un aspecte diferent és si la cerca en PDF's troba o no la ela geminada. D'aquest tema en parlem al següent apartat.

PDF

PDF és un format especificament dissenyat per a representar documents impresos: és a dir documents el font textual dels quals ja ha passat per un renderitzador i se n'ha obtingut una impressió (en el sentit del punt anterior). Un fitxer PDF es doncs la genuïna representació d'un full imprès. També una imatge es podria considerar una possible representació d'un full imprès, això no obstant, una imatge no conserva la propietat de poder ser ampliada sense perdre qualitat. El format PDF permet (tot i qe no garanteix) aquesta propietat desitjable.

D'acord amb el paràgraf anterior, un document PDF, doncs, no conté caràcters sinó glifs i aquesta és l'arrel de tota la confusió. En objecte que conté glifs no es poden cercar caràcters, atès que han desaparegut. Així doncs la cerca en PDF's és, en principi, una eina útil però fora de lloc. Sent així,

  1. Com és que la cerca habitualment funciona?
    Per que en el format PDF la seqüència de glifs es representa sovint amb la seqüència de «caràcters que s'hi corresponen» més el font que cal aplicar. Aquesta correspondència, però, no és perfecta ni pot ser-ho com s'ha vista a l'apartat de glifs. La cerca, doncs, tampoc ho és.
  2. Com es podria solucionar aquest problema?
    Si l'anàlisi és correcta, el problema només té una solució que passa per encabir en el PDF no només els glifs sinó també els text original i la correspondència entre un i altre. Ignoro si pot fer-se sense modificar el format.
  3. No m'ho acabo de creure!
    Doncs segueix llegint Fent l'ullet

Exemples

Els següent exemples volen avalar les tesis anteriors. Són construïts amb LaTeX i LibreOffice i usen el font Linux Libertine G com a suport. Els experiments s'han fet sobre GNU/Debian wheezy.

Exemple 1: LibreOffice

En aquest cas tenim un text sense sentit escrit amb LibreOffice usant Libertine G i activant les lligadures històriques que podeu trobar aquí. Aquest text s'ha convertit a PDF usant també LibreOffice i el resultat és aquest. Si sobre aquest PDF fem una cerca de la lletra «T», veiem que s'identifica el grup «Th» :

Cerca la lletra T però detecta també Th

si afegim una «h» a la cerca, observem com no es troba el grup «Th». En aquesta impressió els caràcters «Th» han esdevingut un sol glif que correspon a la lligadura que es veu a la imatge. Com PDF no té constància dels caràcters originals i el codi del glif no coincideix amb «th», no es troba:

Test 5 exemple 2

La cerca del grup «ct», que correspon també a un sol glif també té un comportament poc intuïtiu. D'altra banda la cerca de «Q» troba tant el glif de cua curta com el de cua llarga.

Exemple 2: XeLaTeX

En aquest cas tenim un text sense sentit escrit amb XeLaTeX usant Libertine G i activant les lligadures històriques que podeu trobar aquí. Aquest text s'ha convertit a PDF usant també LibreOffice i el resultat és aquest. En aquest cas trobareu deficiències similars al cas anterior. Per exemple, a la imatge es veu com dels grups «ct» només se'n troba un: l'altre correspon a un sol glif:

Conclusions

  1. El format PDF és un format final, que substitueix el paper i conté el resultat de renderitzar un text. Conseqüentment conté essencialment glifs i no conté el text original.
  2. En aquestes condicions, la cerca no pot funcionar com un usuari esperaria excepte en aquells PDF que siguin renderització simple de textos en els que no intervinguin sofisticacions tipogràfiques i que, per tant, puguin garantir una correspondència un a un entre caràcter i glif.
  3. El comportament de la cerca no és uniforme entre eines, ja que el seu comportament depèn de com es desa internament la seqüència de glifs, la qual cosa és una decisió que el rasteritzador pot prendre amb total llibertat sense trencar l'estàndard de PDF.
  4. L'hipotètic error de LaTeX que es reportava a la introducció del document no és tal: ho sembla però no ho és. Més aviat es tracta d'un Pseudo-Nyap.

Referències

Sebastià Vila-Marta
Sebastià Vila-Marta diu:
22/11/2012 15:58
Un document per estudiar en relacio a això és aquest: http://www.glyphandcog.com/textext.html
També sembla interessant estudiar el tema de les taules ToUnicode que, potser, serveixen per solventar aquestes dificultas del pdf.
Sebastià Vila-Marta
Sebastià Vila-Marta diu:
22/11/2012 16:28
Ah! Aquest es el fil que s'ha de seguir: http://blogs.adobe.com/[…]/text_content_in_pdf_files.html
Cal tenir present que els consolida la idea de que la forma de representar la ela geminada i el fet de trobar-la dins un pdf són coses desconnexes. També sembla que es consolida la idea de que la «cercabilitat» d'un pdf no és inherent al format pdf i, tot i que desitjable, és opcional.
Sebastià Vila-Marta
Sebastià Vila-Marta diu:
23/11/2012 17:27
Sebastià Vila-Marta
Sebastià Vila-Marta diu:
22/01/2013 19:19
Hi ha un altre cami possible: anomenar els glifs seguint un esquema que els relaciona amb els caràcters unicode originals. Vegi's http://partners.adobe.com/[…]/index_glyph2.html
No és clar si aquesta estratègia encara és vigent o si les aplicacions en fan ús.
Sebastià Vila-Marta
Sebastià Vila-Marta diu:
22/01/2013 19:21
Compte que si això és vàlid cal tenir-ho present en pactar un gliph name per a la ela geminada d'un sol glif