[cairo] ask for advice about cairo's user_font

[James Cloos]

>>>>> "Carl" == Carl Worth <cworth at cworth.org> writes:

Carl> 	evince output/user-font.pdf.argb32.out.pdf
Carl> What I got was:
Carl> 	0eez... cairo user-font
Carl> instead of:
Carl> 	geez... cairo-user-font

Looking at the resulting pdf, in the stream contained in object 3, one
sees:

,----
| /f-0-0 1 Tf
| <00010102030303040506070809040a0b0108>Tj
| 10.5 0 Td
| <0c0d090e0f>Tj
`----

The hex string encodes the text.  Breaking every 8 bits it looks like:

< 00 01 01 02 03 03 03 04 05 06 07 08 09 04 0a 0b 01 08 >< 0c 0d 09 0e 0f >
   g  e  e  z  .  .  .  ␣  c  a  i  r  o  ␣  u  s  e  r     -  f  o  n  t 

(where I used U+2423 OPEN BOX in place of an ascii space).

In the stream contained in object 41, we find:

,----
| <01> <0065>
| <02> <007a>
| <03> <002e>
| <04> <0020>
| <05> <0063>
| <06> <0061>
| <07> <0069>
| <08> <0072>
| <09> <006f>
| <0a> <0075>
| <0b> <0073>
| <0c> <002d>
| <0d> <0066>
| <0e> <006e>
| <0f> <0074>
`----

where you can see the mapping from those 8-bit values to UCS code
points.  Note how <0067> aka U+0067 LATIN SMALL LETTER G is missing.
Note also that U+0030 DIGIT ZERO is also not there.

Object 39 looks like:

,----
| <<
| /Type /Encoding
| /Differences [ 0 /0 /1 /2 /3 /4 /5 /6 /7 /8
| /9 /10 /11 /12 /13 /14 /15 ]
| >>
`----

Object 40 looks like:

,----
| <<
| /0 7 0 R
| /1 9 0 R
| /10 27 0 R
| /11 29 0 R
| /12 31 0 R
| /13 33 0 R
| /14 35 0 R
| /15 37 0 R
| /2 11 0 R
| /3 13 0 R
| /4 15 0 R
| /5 17 0 R
| /6 19 0 R
| /7 21 0 R
| /8 23 0 R
| /9 25 0 R
| >>
`----

The font's main object is object 5.  Object 41 is the /ToUnicode reference
of object 5, object 39 is the /Encoding reference, and object 40 is the
mapping between the glyph names and their procedures.

It looks like the only bug is that object 41 lacks an entry for <00>.

It also looks like xpdf and poppler return an ascii zero if there is no
ToUnicode entry for glyph zero in the font's encoding.

I tried with acrobat5; it tried to pass an ascii NUL when I selected
the g.

Mupdf's text selection is currently disabled, so I was unable to test
what it does.

Looking at cairo-pdf-surface.c, I see:

,----
| /* The CMap specification has a limit of 100 characters per beginbfchar operator */
| _cairo_output_stream_printf (surface->output,
|                              "%d beginbfchar\n",
|                              num_bfchar > 100 ? 100 : num_bfchar);
|
| for (i = 0; i < num_bfchar; i++) {
|     if (i != 0 && i % 100 == 0) {
|         _cairo_output_stream_printf (surface->output,
|                                      "endbfchar\n"
|                                      "%d beginbfchar\n",
|                                      num_bfchar - i > 100 ? 100 : num_bfchar - i);
|     }
`----

That if() is the reason the 0th entry is not output to stream 41.

Given that, the user-fonts should avoid using encoding slot zero for
glyphs, instead starting at encoding slot 1.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6