[NTG-context] follow up

Hans Hagen j.hagen at xs4all.nl
Wed Apr 3 09:06:30 CEST 2019


On 4/3/2019 7:58 AM, Christoph Reller wrote:
> My two cents:
> 
> I don't believe that it is the CIDSet. Both fun.pdf and fun1.pdf have no 
> CIDSet (which is good).
> The (relevant) differences between the two PDFs are:
> - Different ToUnicode
> - Different embedded font stream
> - Minor differences in the font descriptor
> It could be the ToUnicode: If preview is not able to parse the last 
> entry in the ToUnicode table then it may also drop this glyph in its 
> display, although ToUnicode is only relevant for text extraction.

indeed and only very few viewers do that right

> It could be the font stream: In the CFF font file there is a CharSet 
> table that maps character-IDs to glyph-IDs. If preview cannot read the 
> last entry in this table (or the last glyph, glyph nr. 10) then it might 
> drop it.

coul dbe but acrobat is very picky on that as is ghostscript and they work

> By bet is on the ToUnicode, because, usually, if viewers fail to read a 
> font file then they drop the entire font file and not single glyphs.

hm, but i don't think it's different from non lmtx .. i need to check it

> Anyway, both PDFs seem to be valid. But I wonder if the differences in 
> the font descriptor are legitimate (especially StemV):
> Object 9 <-> 7: Different entry Ascent integer value: 1127 <-> 806 in 
> font descriptor dictionary.
> Object 9 <-> 7: Different entry Descent integer value: -280 <-> -194 in 
> font descriptor dictionary.
> Object 9 <-> 7: Different entry StemV integer value: 91 <-> 0 in font 
> descriptor dictionary.

yes, but most of these are bogus and heuristically derived (could be the 
subset or whole font) and quite certainly not used in rendering 
(positioning happens at the pdf level)

we'll see what magic taco has embrained ... he knows apple pdf handling 
in detail so ...

> Cheers,
> Christoph
> 
> On Tue, Apr 2, 2019 at 10:16 PM Hans Hagen <j.hagen at xs4all.nl 
> <mailto:j.hagen at xs4all.nl>> wrote:
> 
>     On 4/2/2019 8:38 PM, Taco Hoekwater wrote:
>      >
>      >
>      >> On 2 Apr 2019, at 17:11, Hans Hagen <j.hagen at xs4all.nl
>     <mailto:j.hagen at xs4all.nl>> wrote:
>      >>
>      >> On 4/2/2019 4:18 PM, Ulrike Fischer wrote:
>      >>> Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen:
>      >>>>> indeed on preview no x shows up but it does in other viewers
>      >>>>>
>      >>>>
>      >>>> Not just the x.
>      >>>> In the second example the s will disappear, be shows up if you
>     add some extra digits, and then dropping the 2
>      >>> I don't have a mac and can't reproduce the problem. But the missing
>      >>> char seems to be always the last one in the beginbfchar/endbfchar
>      >>> list.
>      >>>> The OSX preview is flaky but i’d assume the output of both
>     context version would be similar (enough)
>      >>> The new context adds new lines inside the beginbfchar/endbfchar
>      >>> block. Perhaps this confuses preview and it drops the last entry.
>      >> it is indeed the last one that is the issue but changing spacing
>     or adding dummies doesn't help
>      >
>      > More likely the problem it has is due to the omitted /CIDSet in
>     the font descriptor.
>      >
>      > The error is in the display engine, not the text extractor (since
>     cut&paste work ok).
>      > And that means the problem is almost certainly not the cmap. The
>     only other non-trivial
>      > difference I saw in the old vs. new pdf was that no longer
>     present /CIDSet.
>      >
>      > Unf., generating one in the text editor is bit beyond
>     me-on-the-could mode, so I can
>      > not be certain of that although it seems likely (I checked with
>     FF that the two glyphs
>      > are indeed in the embedded font subset and in the exact slots the
>     pdf says they have, so
>      > that is also unlikely to be the problem.)
>     ok, i'll check that tomorrow ... (cidsets are actually obsolete)
> 
>     Hans
> 
>     -----------------------------------------------------------------
>                                                 Hans Hagen | PRAGMA ADE
>                     Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>              tel: 038 477 53 69 | www.pragma-ade.nl
>     <http://www.pragma-ade.nl> | www.pragma-pod.nl
>     <http://www.pragma-pod.nl>
>     -----------------------------------------------------------------
>     ___________________________________________________________________________________
>     If your question is of interest to others as well, please add an
>     entry to the Wiki!
> 
>     maillist : ntg-context at ntg.nl <mailto:ntg-context at ntg.nl> /
>     http://www.ntg.nl/mailman/listinfo/ntg-context
>     webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
>     archive  : https://bitbucket.org/phg/context-mirror/commits/
>     wiki     : http://contextgarden.net
>     ___________________________________________________________________________________
> 
> 
> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to the Wiki!
> 
> maillist : ntg-context at ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
> 


-- 

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------


More information about the ntg-context mailing list