0.95beta AWT viewer : wrong pages order if forward reference
Some kind of reply to this (old) message : http://markmail.org/message/iyyco7ffxs6qj2i7 I confirm this problem also in 0.95beta The AWT display order is not reversed here : pages 1,2,3...N are displayed in that order : N, 1, 2, 3 ... N-1 This bug only appears if my document has a fo:page-number-citation that refers to the very last page. Thus pages can not be rendered until the very last one is. So there is no equality between awt page number and viewport page number. This is most probably due to the out of order flag, see : https://issues.apache.org/bugzilla/show_bug.cgi?id=41306 Documentation / rendering.xml explains that this workaround has been applied to pdf renderer due to bug. Note : there are other problems with AWT viewer when fo file is updated and one ask for a refresh : pages total number is sometimes false, or display is not refreshed correctly, changing page is not possible... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Table borders : half thickness for spanned columns
Hello, I have a strange behaviour for table rendering, which I can't explain. See example below. Basically, if number-columns-spanned 1, the border-bottom property is applied only to first (original) cell. The next cells only have half the border thickness (example line 2). This is not the case if the row below also has spanned columns (example line 1) Is that expected ? How can I get a 1pt border between lines 2 3 -- without changing row3 ? (row3 is generated by a code that does not handle borders) Example : fo:table table-layout=fixed width=100% border-collapse=collapse fo:table-column column-width=60mm border-left=1pt solid border-right=1pt solid/ fo:table-column column-width=60mm border-left=1pt solid border-right=1pt solid/ fo:table-body fo:table-row border-top=1pt solid border-bottom=solid 1pt fo:table-cell number-columns-spanned=2 fo:block row top=1pt / row bottom=1pt /fo:block /fo:table-cell /fo:table-row fo:table-row border-bottom=1pt solid fo:table-cell number-columns-spanned=2 fo:block no top / row bottom=1pt /fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:block no top/bottom /fo:block /fo:table-cell fo:table-cell fo:block no top/bottom ^^^why 1/2pt ? /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to use glyphs from the Symbol font ?
We generate FOP documents from a *nix workhorse, a rather plain (bare) server that has very minimal graphics font equipment. The current setup works well for current fonts (say, Verdana) and custom-made technical fonts. Now, I would like to use some glyphs from the Symbol font but this raises a few interesting questions which I was not able to answer so far: - it is not quite clear from the documentation whether Base14 fonts need to be declared in fop.xconf [unless I did not look at the right place and missed a point, which is obviously quite possible] - the server certainly has no Symbol font of its own, I can provide a TTF but ttfreader will refuse to generate an XML descriptor (Unicode cmap table not present / Unsupported format - aborting.). - do I need to use the ASCII or Unicode codes for the glyphs; is 'alpha' simply a lowercase a or #xF061; ? I thought this would be a simple item in my todo list but it proves to be more difficult than I expected at first sight :-( Any help appreciated ! Jean-Francois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop instance keeping handle on font file
Thanks for all your answers. Unfortunately, I won't be able to use the GC to free the open handle as: - we will have loads of concurrent fop transformation running in services deployed on a same app server instance, - the open handle makes undeploying a service tricky and manually calling the GC won't ensure immediate garbage collection. I guess for now we can survive with Linux servers as it seems the open handle could be safely ignored on unix systems. Matthieu -- View this message in context: http://www.nabble.com/Fop-instance-keeping-handle-on-font-file-tp18689197p18716243.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to use glyphs from the Symbol font ?
I think there's an issue in how FOP translates the fonts in the Symbol font-family...or at least an inconsistency with other user agents I tried, in particular Internet Explorer and FireFox. I tried to dig into the CodePointMapping class and the magic it's doing on more than one occasion but couldn't quite follow it. The Base14 fonts shouldn't be needed in the FOP configuration, at least not for PDF output (which is all I have experience with). However, the Symbol font doesn't map to the correct code points. In fact it doesn't really map at all. For example, the 'q' character (0x71) should map to the 'θ' character (0x03B8) when Symbol is the font-family, but, if I remember correctly, it simply prints as '#' because 0x71 isn't in the glyph set for the Symbol font. I haven't logged a bug against FOP yet because I haven't had the chance to look into exactly what's going on. But I am pretty certain it's working in a questionable manner. If I wrote the FO itself with the font-family of Symbol and the 'q' character Internet Explorer and FireFox will show that character as 'θ'. If I run the same FO through FOP and view the PDF it creates I see '#'. I own an RTF2FO and RTF2HTML conversion SDK. For the HTML output I just go from RTF2FO and then from FO2HTML. Unfortunately because of this issue I have to manually map the Symbol characters if the final output is FO but not if the final output is HTML so that they can display correctly in both use cases. -Original Message- From: Jean-François El Fouly [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2008 9:54 AM To: fop-users@xmlgraphics.apache.org Subject: How to use glyphs from the Symbol font ? We generate FOP documents from a *nix workhorse, a rather plain (bare) server that has very minimal graphics font equipment. The current setup works well for current fonts (say, Verdana) and custom-made technical fonts. Now, I would like to use some glyphs from the Symbol font but this raises a few interesting questions which I was not able to answer so far: - it is not quite clear from the documentation whether Base14 fonts need to be declared in fop.xconf [unless I did not look at the right place and missed a point, which is obviously quite possible] - the server certainly has no Symbol font of its own, I can provide a TTF but ttfreader will refuse to generate an XML descriptor (Unicode cmap table not present / Unsupported format - aborting.). - do I need to use the ASCII or Unicode codes for the glyphs; is 'alpha' simply a lowercase a or #xF061; ? I thought this would be a simple item in my todo list but it proves to be more difficult than I expected at first sight :-( Any help appreciated ! Jean-Francois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
Re: 0.95beta AWT viewer : wrong pages order if forward reference
I've finally resolved Bugzilla #41306 and committed the necessary change to fix the page order problem: http://svn.apache.org/viewvc?rev=680820view=rev For the other issues: I don't currently have time (or enough of an itch) to debug these problems. Of course, we're always happy to review good patches. On 29.07.2008 13:58:40 Laurent Morel wrote: Some kind of reply to this (old) message : http://markmail.org/message/iyyco7ffxs6qj2i7 I confirm this problem also in 0.95beta The AWT display order is not reversed here : pages 1,2,3...N are displayed in that order : N, 1, 2, 3 ... N-1 This bug only appears if my document has a fo:page-number-citation that refers to the very last page. Thus pages can not be rendered until the very last one is. So there is no equality between awt page number and viewport page number. This is most probably due to the out of order flag, see : https://issues.apache.org/bugzilla/show_bug.cgi?id=41306 Documentation / rendering.xml explains that this workaround has been applied to pdf renderer due to bug. Note : there are other problems with AWT viewer when fo file is updated and one ask for a refresh : pages total number is sometimes false, or display is not refreshed correctly, changing page is not possible... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table borders : half thickness for spanned columns
I don't see the problem. With both 0.94 and 0.95 FOP does exactly what you tell it to do. There's a 1pt border between lines 2 3 when I run your snippet. On 29.07.2008 16:02:21 Laurent Morel wrote: Hello, I have a strange behaviour for table rendering, which I can't explain. See example below. Basically, if number-columns-spanned 1, the border-bottom property is applied only to first (original) cell. The next cells only have half the border thickness (example line 2). This is not the case if the row below also has spanned columns (example line 1) Is that expected ? How can I get a 1pt border between lines 2 3 -- without changing row3 ? (row3 is generated by a code that does not handle borders) Example : fo:table table-layout=fixed width=100% border-collapse=collapse fo:table-column column-width=60mm border-left=1pt solid border-right=1pt solid/ fo:table-column column-width=60mm border-left=1pt solid border-right=1pt solid/ fo:table-body fo:table-row border-top=1pt solid border-bottom=solid 1pt fo:table-cell number-columns-spanned=2 fo:block row top=1pt / row bottom=1pt /fo:block /fo:table-cell /fo:table-row fo:table-row border-bottom=1pt solid fo:table-cell number-columns-spanned=2 fo:block no top / row bottom=1pt /fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:block no top/bottom /fo:block /fo:table-cell fo:table-cell fo:block no top/bottom ^^^why 1/2pt ? /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use glyphs from the Symbol font ?
On 29.07.2008 18:35:33 Griffin,Sean wrote: I think there's an issue in how FOP translates the fonts in the Symbol font-family...or at least an inconsistency with other user agents I tried, in particular Internet Explorer and FireFox. I tried to dig into the CodePointMapping class and the magic it's doing on more than one occasion but couldn't quite follow it. There's not so much magic there. The original Base 14 Symbol font uses the SymbolEncoding (defined in CodePointMapping) which defines a mapping from Unicode characters to glyph indexes. So, whenever a glyph for a character needs to be found for a single-byte font (like Symbol), FOP looks for a glyph index for the input character. The glyph index is then used to paint the glyph. The Base14 fonts shouldn't be needed in the FOP configuration, at least not for PDF output (which is all I have experience with). Right. The Base 14 fonts (Helvetica, Times, Courier, Symbol ZapfDingbats, or equivalent but not necessarily the exactly same fonts) are defined to be available on every PDF and PostScript target device. No configuration required. However, the Symbol font doesn't map to the correct code points. In fact it doesn't really map at all. For example, the 'q' character (0x71) should map to the 'θ' character (0x03B8) when Symbol is the font-family, but, if I remember correctly, it simply prints as '#' because 0x71 isn't in the glyph set for the Symbol font. No, the mapping is correct. You think in terms of one-byte encodings. XSL-FO and therefore FOP is a Unicode application. If you want the theta character (0x03B8, GREEK SMALL LETTER THETA) you need to put the 0x03B8 character in your XSL-FO file. 0x71 always represents a q for which the Symbol font doesn't have a glyph and therefore renders as #. I haven't logged a bug against FOP yet because I haven't had the chance to look into exactly what's going on. But I am pretty certain it's working in a questionable manner. If I wrote the FO itself with the font-family of Symbol and the 'q' character Internet Explorer and FireFox will show that character as 'θ'. If I run the same FO through FOP and view the PDF it creates I see '#'. If RTF2FO produces a 'q' for the theta character in the XSL-FO then that's incorrect. What FO2HTML tool did you use? With RenderX's stylesheet the HTML shows a 'q' in Firefox. I own an RTF2FO and RTF2HTML conversion SDK. For the HTML output I just go from RTF2FO and then from FO2HTML. Unfortunately because of this issue I have to manually map the Symbol characters if the final output is FO but not if the final output is HTML so that they can display correctly in both use cases. -Original Message- From: Jean-François El Fouly [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2008 9:54 AM To: fop-users@xmlgraphics.apache.org Subject: How to use glyphs from the Symbol font ? We generate FOP documents from a *nix workhorse, a rather plain (bare) server that has very minimal graphics font equipment. The current setup works well for current fonts (say, Verdana) and custom-made technical fonts. Now, I would like to use some glyphs from the Symbol font but this raises a few interesting questions which I was not able to answer so far: - it is not quite clear from the documentation whether Base14 fonts need to be declared in fop.xconf [unless I did not look at the right place and missed a point, which is obviously quite possible] - the server certainly has no Symbol font of its own, I can provide a TTF but ttfreader will refuse to generate an XML descriptor (Unicode cmap table not present / Unsupported format - aborting.). - do I need to use the ASCII or Unicode codes for the glyphs; is 'alpha' simply a lowercase a or #xF061; ? I thought this would be a simple item in my todo list but it proves to be more difficult than I expected at first sight :-( Any help appreciated ! Jean-Francois Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop instance keeping handle on font file
On 28.07.2008 21:03:09 Andreas Delmelle wrote: On Jul 28, 2008, at 18:03, Matthieu Siggen wrote: Hi FWIW: While debugging I found out that the fopFactory.newFop call obtains the handle. Unfortunately, the handle seems to be arbitrarly released, ie. a garbage collection is sometimes necessary to free the handle. OK, this seems to indicate that: a) the issue is not located on the FOP-side b) it's not really 'arbitrary' If FOP itself would unnecessarily hold on to a TTF, then a GC will not magically release it. As Jeremias already noted, no obvious bugs present. All FOP does, is open a standard InputStream and properly close it when it is no longer needed. After that, it's up to the InputStream implementation to release the native file handle. It could be that this last step does not occur until the InputStream itself is cleared by the GC. So, it's possible that 'arbitrarily' simply means 'upon the next implicit or explicit garbage-collection'. I consider it highly unlikely (and unwise) that this is implemented like that. Resources need to be releases ASAP. That's what InputStream.close () is there for. Anyway, unfortunately it seems like it's not something we can directly help you with. The only workaround may even be to explicitly ask for Runtime.gc() after every run. Then again, I'm wondering whether this could be a showstopper when running multiple simultaneous FOP-sessions in the same environment. :-S I don't think triggering garbage collection will help at all. Runtime.gc() is not even guaranteed to initiate a GC run. At first I thought that Andreas was a bit quick to give FOP a free pass here. I've enhanced my little InputStream observer framework I once started for XML Graphics Commons so I can observe the close() behaviour. It showed no unclosed streams for the 0.95 branch. Well, I haven't intercepted all InputStreams being opened by FOP, only the font-related ones until I could see the font metric files and the TrueType fonts being loaded. Matthieu, if you do have open file handles that don't seem to be closed, I think you'll have to look towards the author of the JVM you're running on. However, I find it highly unlikely that anyone would make such a mistake in such a central place. Maybe trying another JVM or another JVM version might be a good experiment. What we don't know is what tool you use to observe the file handles and if that produces reliable results. What triggered your coming here in the first place? Was Vista running out of file handles? If you're willing to invest some more time, I can send you a patch on the 0.95 branch with my stream observer so you could run it in your environment. Maybe there's still something wrong with FOP somewhere. I still don't rule that out categorically. But at any rate, I can't reproduce the problem. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
