Pushing the release files to the distribution servers
I will push the release files to the distribution servers early in the afternoon CEST (UTC+2). Simon -- Simon Pepping home page: http://www.leverkruid.eu
DO NOT REPLY [Bug 49621] New: File Descriptor leak in FOUserAgent.imageSessionContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=49621 Summary: File Descriptor leak in FOUserAgent.imageSessionContext Product: Fop Version: 0.95 Platform: PC OS/Version: Windows Vista Status: NEW Severity: major Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: dominik.stad...@gmx.at FOUserAgent holds an element “imageSessionContext” which holds SoftReferences to Source/ImageSource elements via AbstractImageSessionContext.sessionSources. The memory for these items is cleaned correctly when we un-reference the FOUserAgent object, however the Source-items still hold a file-handle via the InputStream that is included in StreamSource/ImageStreamSource object. The effect is that I cannot remove intermediate image files that are used during PDF generation right after generation is done. So file handles are kept open this way and are only given up, when the SoftReference is collected internally. So this can easily cause “out of handle” type of errors if a lot of memory is available and thus SoftReferences are not collected for a long time. Furthermore it hinders cleanup of image files after report generation, i.e. when they are created specifically for the report and should be removed afterwards. This is especially true on platforms which lock open files and do not allow cleanup of those files, e.g. Windows. See also discussion at http://www.mail-archive.com/fop-users%40xmlgraphics.apache.org/msg15411.html -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Pushing the release files to the distribution servers
Done (2010-07-20T14:22:26+02:00). Simon On Tue, Jul 20, 2010 at 09:11:52AM +0200, Simon Pepping wrote: I will push the release files to the distribution servers early in the afternoon CEST (UTC+2). Simon -- Simon Pepping home page: http://www.leverkruid.eu -- Simon Pepping home page: http://www.leverkruid.eu
Re: Font Glyph?
Hi, I’m not keen on adding Yet Another configuratin option to the config file, there are more than enough already. I believe that if a user is advanced enough to be aware that a last resort font can be configured, then they are also able to configure custom fonts so as to avoid any glyph missing warning. Moreover this last resort font is a TrueType font, which is not supported by all output formats yet. Both Type1 and TrueType (OpenType) fonts have a dedicated glyph for unsupported characters. I think this is what FOP should fall back to in case of a missing glyph. Vincent Glenn Adams wrote: Unicode does not prescribe how to render characters for which the assigned font(s) have no corresponding glyph(s). It does, however, make recommendations on how an application or system should handle this case, about which see Unicode 5.1 Section 5.3 Unknown and Missing Characters, under the sub-heading of *Interpretable but Unrenderable Characters*. See also the following FAQ: http://unicode.org/faq/unsup_char.html?PHPSESSID=a05ee80b0f30ee349b9851a929e4e4e6 What FOP should be doing, rather than map an unrenderable character to '#', is to employ a so called Last Resort font, where each defined character is associated with some glyph, e.g., one that indicates the script of the character. In the absence of such a Last Resort font, it is customary to map the character to a glyph depicting an empty box. Unicode has published such a Last Resort font see: http://www.unicode.org/policies/lastresortfont_eula.html A reasonable strategy for FOP might be to allow the user to specify (in the FOP configuration file) a font mapping to a last resort font to be used in such cases. The user would still have to download and install the last resort font on their system, due to licensing reasons. I will post a bug to this effect, and suggesting this solution, if there is not already one present. Some minor modifications to FOP would be required to make use of the configuration information specifying a last resort font, and then using that font when no mapping is present in the assigned font. Regards, Glenn On Mon, Jul 19, 2010 at 11:50 PM, Eric Douglas edoug...@blockhouse.comwrote: I don't understand what unicode.org is saying if it's just referring to what characters the codes should reference if they have to be in the font. Fontforge says U2610 and U2611 are not in the font. Fontforge is an ugly program. It runs within Cygwin, where it displays a window showing the characters in the font, but it doesn't show them all and doesn't have a scrollbar.. I would like an easy way to view the characters in the font to see if I have something available that looks like a square/checkbox. I can only assume the square I'm getting is a default in FOP 0.95 for all missing glyphs. -Original Message- From: J.Pietschmann [mailto:j3322...@yahoo.de] Sent: Saturday, July 17, 2010 11:20 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Font Glyph? On 15.07.2010 22:44, Eric Douglas wrote: Then I pass a text value of #x2611; in my XML. When the transformer uses FOP to translate the XML into output, this prints a square. Have a look at http://www.unicode.org/charts/charindex.html U2611 is BALLOT BOX WITH CHECK, i.e. not a square (U2610 should be a square, are you sure about the entity?) If FOP couldn't find the glyph, it would have printed a # instead. You could use one of the font editors to check whether your font actually has a glyph for the U2611 character (try http://fontforge.sourceforge.net/) I tried replacing my fop.jar with one that I compiled from the Trunk, and instead of printing the square it printed an error message to the Java Console that the font doesn't contain the specified glyph. That's mildly odd, I'd guess your method for telling FOP about your font doesn't work as in Trunk. J.Pietschmann
Adding new version numbers to bugzilla
I registered two JIRA issues: INFRA-2868: Add new version number for XMLGraphicsCommons project in Bugzilla: version 1.4 INFRA-2886: Add new version number for FOP project in Bugzilla: version 1.0 Can someone (Christian) take these actions? Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Font Glyph?
Comment inline. Note that I have assigned the new bug to myself, so I will undertake the work to satisfy this. On Wed, Jul 21, 2010 at 1:25 AM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi, I’m not keen on adding Yet Another configuratin option to the config file, there are more than enough already. What's the purpose in having a configuration file if it isn't used for configuration information? I believe that if a user is advanced enough to be aware that a last resort font can be configured, then they are also able to configure custom fonts so as to avoid any glyph missing warning. That's possible as a temporary work around, but it is not really sufficient in the long term to satisfy documented Unicode behavior. Moreover this last resort font is a TrueType font, which is not supported by all output formats yet. It can be converted. Ideally, FOP would ship with a reasonable built-in last resort font. I will discuss with the Unicode Consortium whether this might be possible. I am acquainted with the original designer of that font, Michael Everson, so perhaps I can obtain a contributed copy that could be distributed. Both Type1 and TrueType (OpenType) fonts have a dedicated glyph for unsupported characters. I think this is what FOP should fall back to in case of a missing glyph. Yes, that is well when there is no last resort font, but it is not really adequate. Vincent Glenn Adams wrote: Unicode does not prescribe how to render characters for which the assigned font(s) have no corresponding glyph(s). It does, however, make recommendations on how an application or system should handle this case, about which see Unicode 5.1 Section 5.3 Unknown and Missing Characters, under the sub-heading of *Interpretable but Unrenderable Characters*. See also the following FAQ: http://unicode.org/faq/unsup_char.html?PHPSESSID=a05ee80b0f30ee349b9851a929e4e4e6 What FOP should be doing, rather than map an unrenderable character to '#', is to employ a so called Last Resort font, where each defined character is associated with some glyph, e.g., one that indicates the script of the character. In the absence of such a Last Resort font, it is customary to map the character to a glyph depicting an empty box. Unicode has published such a Last Resort font see: http://www.unicode.org/policies/lastresortfont_eula.html A reasonable strategy for FOP might be to allow the user to specify (in the FOP configuration file) a font mapping to a last resort font to be used in such cases. The user would still have to download and install the last resort font on their system, due to licensing reasons. I will post a bug to this effect, and suggesting this solution, if there is not already one present. Some minor modifications to FOP would be required to make use of the configuration information specifying a last resort font, and then using that font when no mapping is present in the assigned font. Regards, Glenn On Mon, Jul 19, 2010 at 11:50 PM, Eric Douglas edoug...@blockhouse.com wrote: I don't understand what unicode.org is saying if it's just referring to what characters the codes should reference if they have to be in the font. Fontforge says U2610 and U2611 are not in the font. Fontforge is an ugly program. It runs within Cygwin, where it displays a window showing the characters in the font, but it doesn't show them all and doesn't have a scrollbar.. I would like an easy way to view the characters in the font to see if I have something available that looks like a square/checkbox. I can only assume the square I'm getting is a default in FOP 0.95 for all missing glyphs. -Original Message- From: J.Pietschmann [mailto:j3322...@yahoo.de] Sent: Saturday, July 17, 2010 11:20 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Font Glyph? On 15.07.2010 22:44, Eric Douglas wrote: Then I pass a text value of #x2611; in my XML. When the transformer uses FOP to translate the XML into output, this prints a square. Have a look at http://www.unicode.org/charts/charindex.html U2611 is BALLOT BOX WITH CHECK, i.e. not a square (U2610 should be a square, are you sure about the entity?) If FOP couldn't find the glyph, it would have printed a # instead. You could use one of the font editors to check whether your font actually has a glyph for the U2611 character (try http://fontforge.sourceforge.net/) I tried replacing my fop.jar with one that I compiled from the Trunk, and instead of printing the square it printed an error message to the Java Console that the font doesn't contain the specified glyph. That's mildly odd, I'd guess your method for telling FOP about your font doesn't work as in Trunk. J.Pietschmann
