Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]