[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 <danielrh at dropbox.com> 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 <huw at codeweavers.com> 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.