Re: SVG text misplaced
Hi Matthias, I've just taken a quick look at this and I'm not really sure what you're attempting to do here. Why have you made the viewBox so large and then put scale to fit on the fo:instream-foreign-object? You can reduce the size of the view box such that you don't need to scale-to-fit the SVG image. Is there any reason why you're trying to use such large fonts sizes and drawing space? I'm going to look into why the kerning on that M is so far off, but you may be able to work around this issue. Thanks Mehdi On 24 September 2012 03:20, Matthias Reischenbacher matthias8...@gmx.atwrote: Hi, one of my clients reported a strange problem with SVG text being misplaced in PDF output when very high font size values are used. The sample SVG file also uses very high viewBox values. I created a test case which reproduces the issue when increasing the font size from 2578pt to 2579pt: suddenly the characters are misaligned. The issue doesn't occur when outputting PNG or PS files, so perhaps this is only related to the PDF code. I've been debugging for several hours, but I can't find the cause. I'm attaching a fo file which reproduces the issue and the current PDF output. Perhaps someone can have a look at it and tell me which code part I should check, in order to fix the issue. Thanks for your help. Best regards, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: SVG text misplaced
Ok... This one's a tricksy little badger. Basically, because you're using a font-size that's so large (especially when you convert pts - mpts as FOP works in) we're basically seeing an integer-overflow issue: 2579 pts = 2579000 mpts 833mpts = width of M glyph in Helvetica In Java (read: 32-bit integers), try 2579000 * 833, the result is -2146660296, it should be 2148307000. This means when FOP attempts to draw the glyphs with the appropriate kerning, an erroneous value is being given as the glyph-width of the M character. I'm not really sure if this is a bug, there's always going to be a limitation on the size of the document FOP can produce because we have to work with integers that can overflow, if that limitation is 2147483648 / 1000 / 72 inches (or 29826 inches), I think we have enough scope there to feel assured that we're within the bounds of reasonable use. If you need any help changing your document to be a bit more FOP-friendly, please feel free to ask any further questions and I/we will try and help as much as we can. Hope that helps, Mehdi On 24 September 2012 09:38, mehdi houshmand med1...@gmail.com wrote: Hi Matthias, I've just taken a quick look at this and I'm not really sure what you're attempting to do here. Why have you made the viewBox so large and then put scale to fit on the fo:instream-foreign-object? You can reduce the size of the view box such that you don't need to scale-to-fit the SVG image. Is there any reason why you're trying to use such large fonts sizes and drawing space? I'm going to look into why the kerning on that M is so far off, but you may be able to work around this issue. Thanks Mehdi On 24 September 2012 03:20, Matthias Reischenbacher matthias8...@gmx.atwrote: Hi, one of my clients reported a strange problem with SVG text being misplaced in PDF output when very high font size values are used. The sample SVG file also uses very high viewBox values. I created a test case which reproduces the issue when increasing the font size from 2578pt to 2579pt: suddenly the characters are misaligned. The issue doesn't occur when outputting PNG or PS files, so perhaps this is only related to the PDF code. I've been debugging for several hours, but I can't find the cause. I'm attaching a fo file which reproduces the issue and the current PDF output. Perhaps someone can have a look at it and tell me which code part I should check, in order to fix the issue. Thanks for your help. Best regards, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: nonexistent method signature used in examples (FopFactory.newInstance(URI)
Hi Michael, FOP trunk has had some changes made to it's public API, the link you posted is from trunk and not FOP1.1 RC1. The link below is the 1.1rc1 version of that same file. http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_1rc1/examples/embedding/java/embedding/ExampleXML2PDF.java?revision=1357960view=markup Hope that helps Mehdi On 18 September 2012 13:40, Michael Megliola michael.megli...@gmail.comwrote: (Unless I am missing something...) The code examples for FOP 1.1.RC.1 use a method signature that does not exist in the distribution copy of the binaries: // configure fopFactory as desired final FopFactory fopFactory = FopFactory.newInstance(new File(.).toURI()); The related example is here: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup
Re: SVG text misplaced
Hi Mehdi, thanks a lot for having a closer look! You pointed me in the right direction and I managed to read the char width with the long data type and cast to int after the conversion back to pts. Since this is more a hack than a definitive fix, I'll don't create a patch for now. What do you think of converting all font size related variables from int to long? I didn't do so because a lot of code would have to be modified and I'm not sure how this would impact memory consumption. I'm not in full control of the SVG creation (files are exported from Corel Draw), that's the reason why the SVG file is a bit odd. Normally I don't use fo:instream-foreign-object/, that was only for providing a more compact test case. Thanks again for your help best regards, Matthias On 24.09.2012 06:14, mehdi houshmand wrote: Ok... This one's a tricksy little badger. Basically, because you're using a font-size that's so large (especially when you convert pts - mpts as FOP works in) we're basically seeing an integer-overflow issue: 2579 pts = 2579000 mpts 833mpts = width of M glyph in Helvetica In Java (read: 32-bit integers), try 2579000 * 833, the result is -2146660296, it should be 2148307000. This means when FOP attempts to draw the glyphs with the appropriate kerning, an erroneous value is being given as the glyph-width of the M character. I'm not really sure if this is a bug, there's always going to be a limitation on the size of the document FOP can produce because we have to work with integers that can overflow, if that limitation is 2147483648 / 1000 / 72 inches (or 29826 inches), I think we have enough scope there to feel assured that we're within the bounds of reasonable use. If you need any help changing your document to be a bit more FOP-friendly, please feel free to ask any further questions and I/we will try and help as much as we can. Hope that helps, Mehdi On 24 September 2012 09:38, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: Hi Matthias, I've just taken a quick look at this and I'm not really sure what you're attempting to do here. Why have you made the viewBox so large and then put scale to fit on the fo:instream-foreign-object? You can reduce the size of the view box such that you don't need to scale-to-fit the SVG image. Is there any reason why you're trying to use such large fonts sizes and drawing space? I'm going to look into why the kerning on that M is so far off, but you may be able to work around this issue. Thanks Mehdi On 24 September 2012 03:20, Matthias Reischenbacher matthias8...@gmx.at mailto:matthias8...@gmx.at wrote: Hi, one of my clients reported a strange problem with SVG text being misplaced in PDF output when very high font size values are used. The sample SVG file also uses very high viewBox values. I created a test case which reproduces the issue when increasing the font size from 2578pt to 2579pt: suddenly the characters are misaligned. The issue doesn't occur when outputting PNG or PS files, so perhaps this is only related to the PDF code. I've been debugging for several hours, but I can't find the cause. I'm attaching a fo file which reproduces the issue and the current PDF output. Perhaps someone can have a look at it and tell me which code part I should check, in order to fix the issue. Thanks for your help. Best regards, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
