[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 <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.