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 Keiron Liddle <ke...@aftexsw.com> on 2002/11/20 09:04:58 UTC
Re: Bug 14290 strokeSVGText=false causes space characters to be
rendered incorrectly
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
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