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