DO NOT REPLY [Bug 48111] New: API documentation is not available
https://issues.apache.org/bugzilla/show_bug.cgi?id=48111 Summary: API documentation is not available Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: documentation AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: andr...@apache.org The API documentation links on this page result in 404 errors: http://xmlgraphics.apache.org/fop/dev/api-doc.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.
Conversion of CMYK Image into RGB Image
Hi, As Jeremias stated in the other mail, *[Currently, bitmaps are encoded in sRGB if a CMYK bitmap is encountered for the PostScript render]* Please someone point me to this source code, where the conversion happening for CMYK to RGB. I have given the PSImageUtils class by the Jeremias, but failed to find the code related to this. Thanks in advance, Venkat.
Re: Conversion of CMYK Image into RGB Image
Hi Venkat, that's [1], method encodeRenderedImageAsRGB() in the case of PostScript output. [1] http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/ps/ImageEncodingHelper.java?view=markup HTH On 03.11.2009 17:39:51 Venkat Reddy wrote: Hi, As Jeremias stated in the other mail, *[Currently, bitmaps are encoded in sRGB if a CMYK bitmap is encountered for the PostScript render]* Please someone point me to this source code, where the conversion happening for CMYK to RGB. I have given the PSImageUtils class by the Jeremias, but failed to find the code related to this. Thanks in advance, Venkat. Jeremias Maerki
DO NOT REPLY [Bug 48032] The intermediate file format has xml:space for every text element
https://issues.apache.org/bugzilla/show_bug.cgi?id=48032 --- Comment #3 from Vincent Hennebert vhenneb...@gmail.com 2009-11-03 09:33:18 UTC --- (In reply to comment #2) Question remains: is there any risk that other elements containing text may be affected by that xml:space? To answer that I want to mention why I added the xml:space=preserve in the first place: Editing IF in an XML editor frequently messed up the formatting because of pretty-printing. A comment in the source code explaining that would have been welcome. FOP itself doesn't really profit from it (and can do without). The default behaviour is application-specific which is fine in FOP, but an XML editor doesn't know about that except if there's an XML Schema active in the XML editor which could supply the intended default behaviour. But I haven't tested whether that would really work. So IIUC the xml:space attribute won't even be honoured by the XML editor if the schema is not associated with the document when it's loaded? Unless some code has been written in the editor to recognize the standard attributes in the xml namespace, even if not backed by a schema. Also, is there any testing framework for the intermediate format, to test that change? The only thing we do now is test using XPath statements and I don't think I've written any test that looks for the xml:space attribute. Essentially, you can simply remove the xml:space and the tests will run through as before. As said above, the only case where xml:space is useful is when it comes to manually editing the IF in an XML editor. It avoids breaking the content. If nobody objects I'm going to move the definition of the xml:space attribute to the document element. If its purpose only is to avoid overzealous pretty-printing by XML editors, FOP wouldn't be affected and those editors should still behave properly. Vincent -- 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: DO NOT REPLY [Bug 48108] Special Characters are not rendering
On 03.11.2009 08:45, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=48108 [Snip] Hi Devs, I want to get an opinion: Should we start to emit error messages if there is no glyph for a character in the current font set? Of course, the user shouldn't be drowned in essentially the same message over and over again, perhaps by deferring the message to the end of processing and trying to compressing multiple missing characters to ranges or something like mulitple characters from unicode block NNN didn't have a glyph in font ... J.Pietschmann
Re: DO NOT REPLY [Bug 48108] Special Characters are not rendering
J.Pietschmann wrote: I want to get an opinion: Should we start to emit error messages if there is no glyph for a character in the current font set? Of course, the user shouldn't be drowned in essentially the same message over and over again, perhaps by deferring the message to the end of processing and trying to compressing multiple missing characters to ranges or something like mulitple characters from unicode block NNN didn't have a glyph in font ... +1, especially for the summary report format. ~Chris -- Chris Maden, text nerd URL: http://crism.maden.org/ “The State is that great fiction by which everyone tries to live at the expense of everyone else.” — Frédéric Bastiat, “L’État” GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319
