RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
Here it is, have fun: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/org/apache/fop/svg/PDFTextElementBridge.java?rev=1.3content-type=text/vnd.viewcvs-markup On Thu, 2002-06-13 at 23:44, Vollmer, Thomas - CannonSA wrote: The text is shapes or not depending on whether it is possible to use plain text in the pdf document or not. It looks at the svg text element and if the text is normal then it will not stroke the text but place it directly in pdf. If the text has tspans, fractional fonts, various styling, replaced characters, unknown font etc. then it will be stroked. Could you point me to the place in the source code where these decisions are made? (maybe a link to the web-based CVS?)
RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
Keiron wrote: As I said before. When converting FO to PDF it uses the Configuration. When doing SVG to PDF it (should) uses the batik transocding hints. Whether it is stroked or not depends on how batik is setup with the code. The transcoder that converts SVG to PDF sets it up in a particular way. When converting FO to PDF there is completely different code in the PDFRenderer that sets up batik. They obtain the boolean value for the stroking from different places. Ok, thanks for the pointers. I dug through the code and I think I'm on my way to understanding how all this fits together... Until the PDFTranscoder issue is resolved, I'm probably going to wrap my SVG in an XSL-FO envelope and the use FOP the regular way (i.e. PDFRenderer instead of PDFTranscoder). I was hoping to be able to avoid getting into XSL-FO, but hey, why not... Keiron wrote: Not sure what you mean by that. Why won't making it a BooleanKey fix it? Anyways, I guess my real question is: how can I have my SVG text be not stroked when converted to PDF? (is this a Batik question?) This would have worked before, and did work. Batik has changed in the meantime so it handles this type of thing differently which means that it no longer works. If you are only doing SVG to PDF conversions then try current cvs trunk. How is the current CVS trunk different from the 0.20.3 release in terms of this issue? Keiron wrote: Otherwise wait until there is a release from the trunk (don't ask when that will be). I won't... Thanks! -Thomas If this email is not intended for you, or you are not responsible for the delivery of this message to the addressee, please note that this message may contain ITT Privileged/Proprietary Information. In such a case, you may not copy or deliver this message to anyone. You should destroy this message and kindly notify the sender by reply email. Information contained in this message that does not relate to the business of ITT is neither endorsed by nor attributable to ITT.
RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
On Thu, 2002-06-13 at 03:00, Vollmer, Thomas - CannonSA wrote: How is the current CVS trunk different from the 0.20.3 release in terms of this issue? The trunk is updated to work with the current batik (cvs). The text is shapes or not depending on whether it is possible to use plain text in the pdf document or not. It looks at the svg text element and if the text is normal then it will not stroke the text but place it directly in pdf. If the text has tspans, fractional fonts, various styling, replaced characters, unknown font etc. then it will be stroked. You do not set any value to turn this on or off. This isn't complete yet but should mostly work. Keiron
RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
Keiron wrote: How is the current CVS trunk different from the 0.20.3 release in terms of this issue? The trunk is updated to work with the current batik (cvs). Ok, thanks. The text is shapes or not depending on whether it is possible to use plain text in the pdf document or not. It looks at the svg text element and if the text is normal then it will not stroke the text but place it directly in pdf. If the text has tspans, fractional fonts, various styling, replaced characters, unknown font etc. then it will be stroked. Could you point me to the place in the source code where these decisions are made? (maybe a link to the web-based CVS?) Thanks, Thomas If this email is not intended for you, or you are not responsible for the delivery of this message to the addressee, please note that this message may contain ITT Privileged/Proprietary Information. In such a case, you may not copy or deliver this message to anyone. You should destroy this message and kindly notify the sender by reply email. Information contained in this message that does not relate to the business of ITT is neither endorsed by nor attributable to ITT.
RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
I stand corrected. It does need to be a BooleanKey to work properly. Once I fixed that it doesn't work anymore anyway. I think various changes in batik mean that it needs to be handled differently. On Tue, 2002-06-11 at 00:15, Vollmer, Thomas - CannonSA wrote: Actually, that's not the case. Notice that I'm calling public void setTranscodingHints(Map hints) and NOT public void setTranscodingHints(TranscodingHints hints). The first does this.hints.putAll(hints); (i.e. add), the second one does this.hints = hints; (i.e. replace). The JavaDoc for these two methods is a litte confusing by the way. I had to look at the code to figure this out.
RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
Keiron wrote: I stand corrected. It does need to be a BooleanKey to work properly. [...] Once I fixed that it doesn't work anymore anyway. I think various changes in batik mean that it needs to be handled differently. Not sure what you mean by that. Why won't making it a BooleanKey fix it? Anyways, I guess my real question is: how can I have my SVG text be not stroked when converted to PDF? (is this a Batik question?) Thanks! -Thomas If this email is not intended for you, or you are not responsible for the delivery of this message to the addressee, please note that this message may contain ITT Privileged/Proprietary Information. In such a case, you may not copy or deliver this message to anyone. You should destroy this message and kindly notify the sender by reply email. Information contained in this message that does not relate to the business of ITT is neither endorsed by nor attributable to ITT.
Re: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
try using: addTranscodingHint you are removing transocding hints with the setTranscodingHints. The hint has a StringKey as the key and a Boolean as the value. On Sat, 2002-06-08 at 03:03, Vollmer, Thomas - CannonSA wrote: Map hints = new HashMap(); hints.put(PDFTranscoder.KEY_STROKE_TEXT, Boolean.FALSE); pdfTranscoder.setTranscodingHints(hints); So, I guess in line 174 it expects a Boolean, but I can't get a Boolean into the Map because KEY_STROKE_TEXT is a StringKey. So, KEY_STROKE_TEXT should probably be a BooleanKey!? 1) There seem to be two ways to configure text stroking. What's the difference and which is the preferred way? One is for FOP, ie converting fo to pdf. The other is for batik, converting svg to pdf. The configuration and other things are not related. 2) In the mailing list archive I've read that there are limitations when not stroking text in FOP. What exactly are these limitations? This would probably be the following: - if there is a font or character substitution then it won't work properly - it may ignore things like tspan x and y changes or colourings Thanks for your help, Thomas
RE: Problem with not stroking SVG text (AND BUG IN FOP 0.20.3)
Keiron wrote: try using: addTranscodingHint you are removing transocding hints with the setTranscodingHints. Actually, that's not the case. Notice that I'm calling public void setTranscodingHints(Map hints) and NOT public void setTranscodingHints(TranscodingHints hints). The first does this.hints.putAll(hints); (i.e. add), the second one does this.hints = hints; (i.e. replace). The JavaDoc for these two methods is a litte confusing by the way. I had to look at the code to figure this out. Keiron wrote: The hint has a StringKey as the key and a Boolean as the value. Hmm. Then why do I get this exception: java.lang.IllegalArgumentException: false incompatible with [EMAIL PROTECTED] at org.apache.batik.transcoder.TranscodingHints.put(Unknown Source) at org.apache.batik.transcoder.TranscodingHints.putAll(Unknown Source) at org.apache.batik.transcoder.TranscoderSupport.setTranscodingHints(Unknown Source) [snip] ...when I try this: Map hints = new HashMap(); hints.put(PDFTranscoder.KEY_STROKE_TEXT, Boolean.FALSE); pdfTranscoder.setTranscodingHints(hints); ...and this exception: java.lang.ClassCastException: java.lang.String at org.apache.fop.svg.PDFTranscoder.transcode(PDFTranscoder.java:174) at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source) ...when I try this: Map hints = new HashMap(); hints.put(PDFTranscoder.KEY_STROKE_TEXT, false); pdfTranscoder.setTranscodingHints(hints); Keiron wrote: 1) There seem to be two ways to configure text stroking. What's the difference and which is the preferred way? One is for FOP, ie converting fo to pdf. The other is for batik, converting svg to pdf. The configuration and other things are not related. Ok, so I guess [1] is for FOP and [2] is for Batik. [1] org.apache.fop.configuration.Configuration.put(strokeSVGText, Boolean.FALSE); [2] transcodingHints.put(PDFTranscoder.KEY_STROKE_TEXT, Boolean.FALSE); Keiron wrote: 2) In the mailing list archive I've read that there are limitations when not stroking text in FOP. What exactly are these limitations? This would probably be the following: - if there is a font or character substitution then it won't work properly - it may ignore things like tspan x and y changes or colourings Ok, thanks. Regards, Thomas If this email is not intended for you, or you are not responsible for the delivery of this message to the addressee, please note that this message may contain ITT Privileged/Proprietary Information. In such a case, you may not copy or deliver this message to anyone. You should destroy this message and kindly notify the sender by reply email. Information contained in this message that does not relate to the business of ITT is neither endorsed by nor attributable to ITT.
