Re: SVG Font quality
As I suspected. The SVG contains tspan elements which are rendered as shapes by 0.92beta to be on the safe side. What you're seeing is only the effect of painting vector graphics (as opposed to painting text). If you zoom in on the text the quality will get better. It doesn't look bad if you print it, does it? Some SVG text elements are difficult to be painted using text operators in PDF so that's when we fall back to painting as shapes (prime example: text on a path). The tspan element in your case are pretty simple which could actually allow painting as text but the code is not that refined, yet. The regression from 0.20.5 can be explained that 0.20.5 didn't care much about tspan elements which could lead to poor output. 0.92 is more careful. On 12.06.2006 18:03:49 Raphael Parree wrote: Jeremias, Attached is the SVG. The PDF viewer I'm using is Adobe Acrobat (7.something). The quality used to be great with the FOP 0.20.5 bundle. I would assume it is a batik problem, if the batik-1.6-squiggle viewer would not show the rendered SVG in the appropriate quality. Cheers., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 09:59 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality The GIF helps showing the symptom but not the reason for the problem. Fonts can generally be rendered in two ways: text operations and vector graphics. In your case, I assume the text was rendered as vector graphics. If smooth line art is disabled (or not supported) in your PDF viewer, it could explain the poorer quality. It could help to see your SVG file. But also note that some text elements cannot be painted as text operations, yet. The choice which kind is used depends on the SVG content. On 06.06.2006 13:11:41 Raphael Parree wrote: Hi, I noticed the quality of my fonts in the SVG is noticeably less in 0.92b than in was with 0.20.5. Attached is an example (left is the PDF, right is batik-1.6-squiggle). I am embedding the fonts (Verdana) in my PDF. The SVG is included using defaults (with 72 as the resolution). Any clues? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SVG Font quality
Jeremias, You are right when zooming in the text looks better, and indeed the printing quality is good. However we also generate a PDF which is used as a presentation and is therefore not printed. Having both a presentation and a book was actually the reason to move to SVG as they scale well in printed form as on screen. :( Will the code be refined in the near future :) Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 13 June 2006 08:52 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality As I suspected. The SVG contains tspan elements which are rendered as shapes by 0.92beta to be on the safe side. What you're seeing is only the effect of painting vector graphics (as opposed to painting text). If you zoom in on the text the quality will get better. It doesn't look bad if you print it, does it? Some SVG text elements are difficult to be painted using text operators in PDF so that's when we fall back to painting as shapes (prime example: text on a path). The tspan element in your case are pretty simple which could actually allow painting as text but the code is not that refined, yet. The regression from 0.20.5 can be explained that 0.20.5 didn't care much about tspan elements which could lead to poor output. 0.92 is more careful. On 12.06.2006 18:03:49 Raphael Parree wrote: Jeremias, Attached is the SVG. The PDF viewer I'm using is Adobe Acrobat (7.something). The quality used to be great with the FOP 0.20.5 bundle. I would assume it is a batik problem, if the batik-1.6-squiggle viewer would not show the rendered SVG in the appropriate quality. Cheers., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 09:59 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality The GIF helps showing the symptom but not the reason for the problem. Fonts can generally be rendered in two ways: text operations and vector graphics. In your case, I assume the text was rendered as vector graphics. If smooth line art is disabled (or not supported) in your PDF viewer, it could explain the poorer quality. It could help to see your SVG file. But also note that some text elements cannot be painted as text operations, yet. The choice which kind is used depends on the SVG content. On 06.06.2006 13:11:41 Raphael Parree wrote: Hi, I noticed the quality of my fonts in the SVG is noticeably less in 0.92b than in was with 0.20.5. Attached is an example (left is the PDF, right is batik-1.6-squiggle). I am embedding the fonts (Verdana) in my PDF. The SVG is included using defaults (with 72 as the resolution). Any clues? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TOC problem (text-align-last)
Title: TOC problem (text-align-last)
Hi,
I have seen some posts on this earlier this year (e.g, http://www.nabble.com/TOC-problem-with-text-align-last-t1432522.html#a3864138), but no solution that works for me
The problem is quite simple; in my TOC the page numbers are not correctly aligned. In FOP 0.20.5 it worked, but with 0.92b (or the latest trunk) version it doesnt.
I believe my code is straightforward:
fo:block text-align-last=justify font-family=Verdana font-size=12pt font-weight=bold
space-before=12pt space-after=6pt
xsl:apply-templates select=cws:title/
fo:leader leader-pattern=dots/
fo:page-number-citation ref-id={generate-id()}/
/fo:block
fo:block text-align-last=justify start-indent=0.76cm font-family=Verdana font-size=12pt
space-before=6pt space-after=3pt space-after.conditionality=retain
space-before.conditionality=retain
xsl:choose
xsl:when test=cws:lesson
xsl:apply-templates select=cws:title/
/xsl:when
xsl:when test=cwe:exercise
xsl:apply-templates select=cwe:info/cwe:title/
/xsl:when
/xsl:choose
fo:leader leader-pattern=dots/
fo:page-number-citation ref-id={generate-id()}/
/fo:block
fo:block space-before.conditionality=retain space-after.conditionality=retain
space-after=3pt space-before=6pt font-size=12pt font-family=Verdana
start-indent=0.76cm text-align-last=justifyDefine the System Requirements (Creating the
PIM)fo:leader leader-pattern=dots/fo:page-number-citation ref-id=N10A17
//fo:block
Any clues?
Tx.,
Raphael
Re: SVG Font quality
It's not on my list, sorry. But you've got the source code. :-) On 13.06.2006 09:47:12 Raphael Parree wrote: Jeremias, You are right when zooming in the text looks better, and indeed the printing quality is good. However we also generate a PDF which is used as a presentation and is therefore not printed. Having both a presentation and a book was actually the reason to move to SVG as they scale well in printed form as on screen. :( Will the code be refined in the near future :) Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 13 June 2006 08:52 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality As I suspected. The SVG contains tspan elements which are rendered as shapes by 0.92beta to be on the safe side. What you're seeing is only the effect of painting vector graphics (as opposed to painting text). If you zoom in on the text the quality will get better. It doesn't look bad if you print it, does it? Some SVG text elements are difficult to be painted using text operators in PDF so that's when we fall back to painting as shapes (prime example: text on a path). The tspan element in your case are pretty simple which could actually allow painting as text but the code is not that refined, yet. The regression from 0.20.5 can be explained that 0.20.5 didn't care much about tspan elements which could lead to poor output. 0.92 is more careful. On 12.06.2006 18:03:49 Raphael Parree wrote: Jeremias, Attached is the SVG. The PDF viewer I'm using is Adobe Acrobat (7.something). The quality used to be great with the FOP 0.20.5 bundle. I would assume it is a batik problem, if the batik-1.6-squiggle viewer would not show the rendered SVG in the appropriate quality. Cheers., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 09:59 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality The GIF helps showing the symptom but not the reason for the problem. Fonts can generally be rendered in two ways: text operations and vector graphics. In your case, I assume the text was rendered as vector graphics. If smooth line art is disabled (or not supported) in your PDF viewer, it could explain the poorer quality. It could help to see your SVG file. But also note that some text elements cannot be painted as text operations, yet. The choice which kind is used depends on the SVG content. On 06.06.2006 13:11:41 Raphael Parree wrote: Hi, I noticed the quality of my fonts in the SVG is noticeably less in 0.92b than in was with 0.20.5. Attached is an example (left is the PDF, right is batik-1.6-squiggle). I am embedding the fonts (Verdana) in my PDF. The SVG is included using defaults (with 72 as the resolution). Any clues? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TTF and OTF fonts in FOP 0.92
Hi: While rendering fonts (TTF) from XSl-fo to PDF, the fonts are not shown as smooth as it should be. The font I am using is a TTF font named Univers LT 57 Condensed. The corresponding entry in the FOP configuration file is as follows: font metrics-url=./fonts/lte50146.xml kerning=yes embed-url=./fonts/lte50146.ttf font-triplet name=Univers LT 57 Condensed style=normal weight=normal / /font After seeing it in Acrobat Reader, by making smooth text option off, the texts look much better. It seems somehow the smoothening of the characters in the specified font is not happening properly. What could be the reason? Are we missing something in setting up the configurations? Another question, is FOP 0.92 using SVG to render fonts in PDF? Also, how do I incorporate OTF? Thanking you in advance, Regards, Debasish Jana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multi-page pdf from swing Jcomponents
I've big troubles trying to stream large JComponents into a multi-page pdf. Watching other threads I learn there's no way to make this in a simple way; what's the best way to solve my problem? I want to make photoes of my JPanels, with the ability to split them over multi-pages, without page break JPanel's child components. I need to override paintComponent() and related methods, or just fop give me some other useful instruments? Could an intermediate SVG encoding step help me for this porpouse? Best regards, Fabio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
page-number-citation change btw .20.5 and .92beta?
Hi, I'm trying to upgrade a conversion to use .92beta instead of .20.5. One thing that's breaking is that my page numbers in the TOC don't show up in the PDF file anymore. Has something changed in this implementation? Here's a snippiet of my generated .fo code: fo:block margin-left=4.9pc margin-top=6pt text-align-last=justify fo:inline font-weight=boldIntroduction/fo:inline fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=N20006/ /fo:block (This id does exist in the file, BTW.) In the output, I see Introduction and the dot leader, but no page number. FWIW, I'm using Acrobat Reader 6.0. Thanks for any help! -- View this message in context: http://www.nabble.com/page-number-citation-change-btw-.20.5-and-.92beta--t1782147.html#a4852988 Sent from the FOP - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: page-number-citation change btw .20.5 and .92beta?
Mark_Fletcher wrote: I'm trying to upgrade a conversion to use .92beta instead of .20.5. One thing that's breaking is that my page numbers in the TOC don't show up in the PDF file anymore. Has something changed in this implementation? The new layout engine is an almost complete new implementation, so yes, there has something changed. The new release still has some problems with forward referencing page number citations, although problems causing the whole number to disappear should have been fixed meanwhile. The only way around seems to be to avoid forward references, i.e. putting the TOC at the end of the document. Another hint: fo:inline font-weight=boldIntroduction/fo:inline FOP 0.92ff is more compliant than 0.20.5, which means that processing fo:inline is much more expensive now. You should use fo:wrapper for changing font styles. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: schema validation
Rick Roen wrote: I have substituted Saxon for Xalan so I could get XSLT 2.0 and XPath 2.0 support, but other than that, I think its pretty standard. Saxon is an XSLT processor. XSLT processors don't do the validation. XML parsers or specific validation processors are responsible for validation. Do you notice anything else wrong with anything? I checked the Xerces site and didn't notice anything. It's common that XSLT processors disable validation if they allocate the XML parser, although I thought this only disables to validation against a DTD. Maybe Xerces has to be told explicitly to validate against an XSchema. There ought to be ways to do this without hacking the code, I vaguely remember setting a Java system property (which can bo done on the command line). Maybe you should ask on the Xerces user list for more help. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TTF and OTF fonts in FOP 0.92
Debasish Jana wrote: While rendering fonts (TTF) from XSl-fo to PDF, the fonts are not shown as smooth as it should be. ... After seeing it in Acrobat Reader, by making smooth text option off, the texts look much better. Is this smooth text option an option in Acrobat Reader? If so, that's not a problem with FOP but rather with the combination of the font, your display and/or the graphics driver, and perhaps Acrobat Reader itself. It seems somehow the smoothening of the characters in the specified font is not happening properly. Well, I used to associate smoothing for fonts with anti-aliasing. This is known to give bad results under for some fonts on mainstream computer displays and certain other circumstances. A font with Condensed in its name is a candidate for such a situation, for reasons given further down. The print-out should be ok, because printers generally have a much higher resolution than computer displays. What could be the reason? Are we missing something in setting up the configurations? I don't think there is anything FOP can do in this situation. If you want good results on a computer display, use a font which has a stroke width of at least one display pixel for mainstream displays (a 19 at 1280x1024 has ~84dpi) for common font sizes (12pt). The letters should mainly use exactly horizontal and vertical strokes. Thin, slightly slanted lines fare horrible if anti-aliasing is enabled. Another question, is FOP 0.92 using SVG to render fonts in PDF? That's a strange question. Why do you ask this? And no, FOP doesn't render fonts in regular FO content at all; rather, the glyph definitions are embedded (for user fonts) into the PDF. Rendering is done by the PDF viewer, which usually delegates the job to the graphics system on the host machine. Also, how do I incorporate OTF? OTF is an enhancement of the TTF format. You can try to handle it exactly like a TTF, i.e. generating a metrics file using TTFFile etc. If you get an error (likely), the answer is no chance, pal. Note that not getting an error while generating a metrics file doesn't necessarily mean all is well. Some font editors are said to be able to downgrade OTF fonts to TTF automatically with reasonably good results, you might want to ask on an appropriate forum. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: schema validation
Rick Roen wrote: The free Saxon is an XSLT processor, but the one you pay for does include schema support. When you assign a schema in the XSLT, you get a message from Saxon that you need the other version. You seem to confuse validating against a schema with XSLT 2.0 schema support for data typing. I talked about the former, while you seem to want the latter (or not). In this case you might want to ask on a Saxon specific forum for more help (the commercial Saxon is currently the only usable XSLT 2.0 processor with schema support). This is becoming OT for this list. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
