You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Karen Lease <kl...@club-internet.fr> on 2002/11/19 23:38:21 UTC
Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Hi all (and especially Jeremias or other font experts),
This bug seems to be due to the way we generate the 'loca' table in the
embedded font subsets (CID fonts). In fact, it has offsets to the
correct glyph descriptions, but the offsets are not in ascending order.
Since it seems that the length of the glyph description is found by
subtracting the offset to the glyph from the offset for the next glyph
in the loca table, this does not work. For Acrobat, as long as there
actually _is_ a glyph description, it seems to work anyway. However for
space characters, there is no glyph. Acrobat thinks there is because of
the offset, so it draws the glyph that _is_ stored at the offset.
This only shows up with SVG text because it has embedded spaces. The
spaces in normal text are generally turned into explicit offsets and not
drawn as such.
The attached diff fixes the bug; though there are perhaps more elegant
ways to do it. Does anyone see anything wrong with this idea?
If not, I'll commit asap.
In fact, using this fix, xpdf now also works with embedded fonts,
whereas before it produced garbage.
Regards,
Karen Lease
(Lately very overworked) Senior Software Developer
SPX Valley Forge
Paris/Munich
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Karen
Well, I don't call myself a font expert, yet, though I'm working hard to
get to Tore's level. I haven't had much contact with TrueType fonts, so
I'm probably not the right person to answer your proposal but I think if
it works it's ok.
On 19.11.2002 23:38:21 Karen Lease wrote:
> Hi all (and especially Jeremias or other font experts),
>
> This bug seems to be due to the way we generate the 'loca' table in the
> embedded font subsets (CID fonts). In fact, it has offsets to the
> correct glyph descriptions, but the offsets are not in ascending order.
> Since it seems that the length of the glyph description is found by
> subtracting the offset to the glyph from the offset for the next glyph
> in the loca table, this does not work. For Acrobat, as long as there
> actually _is_ a glyph description, it seems to work anyway. However for
> space characters, there is no glyph. Acrobat thinks there is because of
> the offset, so it draws the glyph that _is_ stored at the offset.
>
> This only shows up with SVG text because it has embedded spaces. The
> spaces in normal text are generally turned into explicit offsets and not
> drawn as such.
>
> The attached diff fixes the bug; though there are perhaps more elegant
> ways to do it. Does anyone see anything wrong with this idea?
> If not, I'll commit asap.
Please do. We can always change again if it doesn't work out.
The only other idea that's coming to my mind is to enhance the
TextPainter so it doesn't paint spaces but also just advanced the
current position. But that only complicates the code there and I don't
know if it's worth it.
> In fact, using this fix, xpdf now also works with embedded fonts,
> whereas before it produced garbage.
I'd like to point out that IMO it's important to separate TrueType and
Type 1 support where embedded fonts are concerned. I'm pretty sure I
have identified a problem with embedded Type 1 fonts that leads to
errors on certain PDF and PostScript RIP engines. I don't know about
xpdf. I intend to fix that very soon now.
> Regards,
> Karen Lease
>
> (Lately very overworked) Senior Software Developer
> SPX Valley Forge
> Paris/Munich
Have you already signed up for the germany-based committers meeting? :-)
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Posted by Karen Lease <kl...@club-internet.fr>.
Thanks, I probably would have gotten around to it, but glad it's done.
-Karen
Jeremias Maerki wrote:
> I've committed your change to the trunk. I hope I haven't crossed your
> path. I've had a few other things I wanted to do in this region.
>
> On 20.11.2002 22:40:50 Karen Lease wrote:
>
>>Hi Keiron,
>>
>>Feels good to do a little FOP :-)
>>It's mostly work-related right now which explains why I'm hacking around
>>in the maintenance branch. But it's better than nothing.
>>
>>I think this particular patch should work in trunk too, assuming no
>>major differences in the embedding logic. I'll look into it.
>>
>>-Karen
>>
>>Keiron Liddle wrote:
>>
>>
>>>Hi Karen,
>>>
>>>Welcome back.
>>>
>>>Well if it works it looks good to me but I'm no font expert.
>>>Could that also be applied to trunk?
>>>
>>>Be careful the style police might get onto you.
>>>
>>>Keiron.
>>>
>>>On Tue, 2002-11-19 at 23:38, Karen Lease wrote:
>>>
>>>
>>>>Hi all (and especially Jeremias or other font experts),
>>>>
>>>>This bug seems to be due to the way we generate the 'loca' table in the
>>>>embedded font subsets (CID fonts). In fact, it has offsets to the
>>>>correct glyph descriptions, but the offsets are not in ascending order.
>>>>Since it seems that the length of the glyph description is found by
>>>>subtracting the offset to the glyph from the offset for the next glyph
>>>>in the loca table, this does not work. For Acrobat, as long as there
>>>>actually _is_ a glyph description, it seems to work anyway. However for
>>>>space characters, there is no glyph. Acrobat thinks there is because of
>>>>the offset, so it draws the glyph that _is_ stored at the offset.
>>>>
>>>>This only shows up with SVG text because it has embedded spaces. The
>>>>spaces in normal text are generally turned into explicit offsets and not
>>>>drawn as such.
>>>>
>>>>The attached diff fixes the bug; though there are perhaps more elegant
>>>>ways to do it. Does anyone see anything wrong with this idea?
>>>>If not, I'll commit asap.
>>>>
>>>>
>>>>In fact, using this fix, xpdf now also works with embedded fonts,
>>>>whereas before it produced garbage.
>>>>
>>>>Regards,
>>>>Karen Lease
>>>>
>>>>(Lately very overworked) Senior Software Developer
>>>>SPX Valley Forge
>>>>Paris/Munich
>>>>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Posted by Jeremias Maerki <de...@greenmail.ch>.
I've committed your change to the trunk. I hope I haven't crossed your
path. I've had a few other things I wanted to do in this region.
On 20.11.2002 22:40:50 Karen Lease wrote:
> Hi Keiron,
>
> Feels good to do a little FOP :-)
> It's mostly work-related right now which explains why I'm hacking around
> in the maintenance branch. But it's better than nothing.
>
> I think this particular patch should work in trunk too, assuming no
> major differences in the embedding logic. I'll look into it.
>
> -Karen
>
> Keiron Liddle wrote:
>
> > Hi Karen,
> >
> > Welcome back.
> >
> > Well if it works it looks good to me but I'm no font expert.
> > Could that also be applied to trunk?
> >
> > Be careful the style police might get onto you.
> >
> > Keiron.
> >
> > On Tue, 2002-11-19 at 23:38, Karen Lease wrote:
> >
> >>Hi all (and especially Jeremias or other font experts),
> >>
> >>This bug seems to be due to the way we generate the 'loca' table in the
> >>embedded font subsets (CID fonts). In fact, it has offsets to the
> >>correct glyph descriptions, but the offsets are not in ascending order.
> >>Since it seems that the length of the glyph description is found by
> >>subtracting the offset to the glyph from the offset for the next glyph
> >>in the loca table, this does not work. For Acrobat, as long as there
> >>actually _is_ a glyph description, it seems to work anyway. However for
> >>space characters, there is no glyph. Acrobat thinks there is because of
> >>the offset, so it draws the glyph that _is_ stored at the offset.
> >>
> >>This only shows up with SVG text because it has embedded spaces. The
> >>spaces in normal text are generally turned into explicit offsets and not
> >>drawn as such.
> >>
> >>The attached diff fixes the bug; though there are perhaps more elegant
> >>ways to do it. Does anyone see anything wrong with this idea?
> >>If not, I'll commit asap.
> >>
> >>
> >>In fact, using this fix, xpdf now also works with embedded fonts,
> >>whereas before it produced garbage.
> >>
> >>Regards,
> >>Karen Lease
> >>
> >>(Lately very overworked) Senior Software Developer
> >>SPX Valley Forge
> >>Paris/Munich
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Keiron,
Feels good to do a little FOP :-)
It's mostly work-related right now which explains why I'm hacking around
in the maintenance branch. But it's better than nothing.
I think this particular patch should work in trunk too, assuming no
major differences in the embedding logic. I'll look into it.
-Karen
Keiron Liddle wrote:
> Hi Karen,
>
> Welcome back.
>
> Well if it works it looks good to me but I'm no font expert.
> Could that also be applied to trunk?
>
> Be careful the style police might get onto you.
>
> Keiron.
>
> On Tue, 2002-11-19 at 23:38, Karen Lease wrote:
>
>>Hi all (and especially Jeremias or other font experts),
>>
>>This bug seems to be due to the way we generate the 'loca' table in the
>>embedded font subsets (CID fonts). In fact, it has offsets to the
>>correct glyph descriptions, but the offsets are not in ascending order.
>>Since it seems that the length of the glyph description is found by
>>subtracting the offset to the glyph from the offset for the next glyph
>>in the loca table, this does not work. For Acrobat, as long as there
>>actually _is_ a glyph description, it seems to work anyway. However for
>>space characters, there is no glyph. Acrobat thinks there is because of
>>the offset, so it draws the glyph that _is_ stored at the offset.
>>
>>This only shows up with SVG text because it has embedded spaces. The
>>spaces in normal text are generally turned into explicit offsets and not
>>drawn as such.
>>
>>The attached diff fixes the bug; though there are perhaps more elegant
>>ways to do it. Does anyone see anything wrong with this idea?
>>If not, I'll commit asap.
>>
>>
>>In fact, using this fix, xpdf now also works with embedded fonts,
>>whereas before it produced garbage.
>>
>>Regards,
>>Karen Lease
>>
>>(Lately very overworked) Senior Software Developer
>>SPX Valley Forge
>>Paris/Munich
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Bug 14290 strokeSVGText=false causes space characters to be
rendered incorrectly
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi Karen,
Welcome back.
Well if it works it looks good to me but I'm no font expert.
Could that also be applied to trunk?
Be careful the style police might get onto you.
Keiron.
On Tue, 2002-11-19 at 23:38, Karen Lease wrote:
> Hi all (and especially Jeremias or other font experts),
>
> This bug seems to be due to the way we generate the 'loca' table in the
> embedded font subsets (CID fonts). In fact, it has offsets to the
> correct glyph descriptions, but the offsets are not in ascending order.
> Since it seems that the length of the glyph description is found by
> subtracting the offset to the glyph from the offset for the next glyph
> in the loca table, this does not work. For Acrobat, as long as there
> actually _is_ a glyph description, it seems to work anyway. However for
> space characters, there is no glyph. Acrobat thinks there is because of
> the offset, so it draws the glyph that _is_ stored at the offset.
>
> This only shows up with SVG text because it has embedded spaces. The
> spaces in normal text are generally turned into explicit offsets and not
> drawn as such.
>
> The attached diff fixes the bug; though there are perhaps more elegant
> ways to do it. Does anyone see anything wrong with this idea?
> If not, I'll commit asap.
>
>
> In fact, using this fix, xpdf now also works with embedded fonts,
> whereas before it produced garbage.
>
> Regards,
> Karen Lease
>
> (Lately very overworked) Senior Software Developer
> SPX Valley Forge
> Paris/Munich
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org