Re: [1/3] wineps.drv: Avoid marking composite unicode subglyphs as downloaded (resend)

[Huw Davies]

On Mon, Sep 08, 2014 at 09:18:51PM -0700, Daniel Horn wrote:
> Fixes a bug with caching composite unicode glyphs (if a ñ came before any n in the document,
> then all subsequent n's would appear as a box)
> This was because the glyph was marked as having been sent down when it was only a component
> of a more complex glyph

This shouldn't be necessary, I suspect something else is going wrong.
If the 'n' has been downloaded as part of a 'ñ' then it really
shouldn't be necessary to download the 'n' again.

Huw.

[1/3] wineps.drv: Avoid marking composite unicode subglyphs as downloaded (resend)

[Daniel Horn]

I have an example where that's not the case where an ñ comes first
It downloads a *composite* character which, as far as the pdf is
concerned, is just a very complicated set of strokes that looks like a
ñ. But while it looks up the n to draw those strokes, the actual
definition of the n itself is *not* in the resulting .ps file (I
checked it by hand)
It only defines the ñ as a font subset, and then all subsequent n's
come in as squares.

The problem is only encountered when composite unicode-named glyphs
are being downloaded. Thus the bug is only being triggered when patch
2/3 is applied
but patch 1/3 solves it.

On Tue, Sep 9, 2014 at 2:17 AM, Huw Davies  wrote:
> On Mon, Sep 08, 2014 at 09:18:51PM -0700, Daniel Horn wrote:
> > Fixes a bug with caching composite unicode glyphs (if a ñ came before any n in the document,
> > then all subsequent n's would appear as a box)
> > This was because the glyph was marked as having been sent down when it was only a component
> > of a more complex glyph
>
> This shouldn't be necessary, I suspect something else is going wrong.
> If the 'n' has been downloaded as part of a 'ñ' then it really
> shouldn't be necessary to download the 'n' again.
>
> Huw.

[1/3] wineps.drv: Avoid marking composite unicode subglyphs as downloaded (resend)

[Daniel Horn]

the errant postscript looks like so:

begin
 /g0051 81 def
end
pop pop
16 522
<0001001604450296054c0019006e4043
a70fb902b60f038907860f861303760f
77138b020366137a027907036a026907
640f039902960fa80203000134118109
770c0d168104040d000c680f0d1f0d2f
0d030db80170b7006801191a58de182b
4e10f44dedfd5ded003f3c10ed103cf4
fdf43c3130015d5d5d5d5d5d13233636
33321716163332363733160606232227
2626232207063620046a4e29222da528
20310e1f01335d2f4f753f2c1529180b
0449897a0d116d36555d6d3d502b1224
1100>
/TimesNewRomanPSMT findfont exch 1 index
havetype42gdir
{/GlyphDirectory get begin 215 exch def end}
{/sfnts get 4 index get 3 index 2 index putinterval pop}
ifelse
/CharStrings get
begin
 /g00d7 215 def
end
pop pop
13 4990
<ffff000c000003f7054c022600510000
010700d700ab00000021401301404150
419041035041014102d2482b010145b9
02ad0029002b012b715d3500>
/TimesNewRomanPSMT findfont exch 1 index
havetype42gdir
{/GlyphDirectory get begin 120 exch def end}
{/sfnts get 4 index get 3 index 2 index putinterval pop}
ifelse
/CharStrings get
begin
 /uni00F1 120 def
end
pop pop
/uni00F1 glyphshow

Perhaps another idea would be to keep multiple tables of booleans
about whether they were downloaded, one for /uni definitions and one
for non unicode anonymous glyph /g definitions?

On Tue, Sep 9, 2014 at 2:25 AM, Daniel Horn  wrote:
> I have an example where that's not the case where an ñ comes first
> It downloads a *composite* character which, as far as the pdf is
> concerned, is just a very complicated set of strokes that looks like a
> ñ. But while it looks up the n to draw those strokes, the actual
> definition of the n itself is *not* in the resulting .ps file (I
> checked it by hand)
> It only defines the ñ as a font subset, and then all subsequent n's
> come in as squares.
>
> The problem is only encountered when composite unicode-named glyphs
> are being downloaded. Thus the bug is only being triggered when patch
> 2/3 is applied
> but patch 1/3 solves it.
>
> On Tue, Sep 9, 2014 at 2:17 AM, Huw Davies  wrote:
> > On Mon, Sep 08, 2014 at 09:18:51PM -0700, Daniel Horn wrote:
> > > Fixes a bug with caching composite unicode glyphs (if a ñ came before any n in the document,
> > > then all subsequent n's would appear as a box)
> > > This was because the glyph was marked as having been sent down when it was only a component
> > > of a more complex glyph
> >
> > This shouldn't be necessary, I suspect something else is going wrong.
> > If the 'n' has been downloaded as part of a 'ñ' then it really
> > shouldn't be necessary to download the 'n' again.
> >
> > Huw.