Re: svn commit: r331757 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/RTFHandler.java
[EMAIL PROTECTED] schrieb: Author: manuel Date: Tue Nov 8 01:42:43 2005 New Revision: 331757 URL: http://svn.apache.org/viewcvs?rev=331757view=rev Log: Another character encoding update Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/RTFHandler.java [..] * @author Bertrand Delacretaz [EMAIL PROTECTED] * @author Trembicki-Guy, Ed [EMAIL PROTECTED] - * @author Boris Poudérous [EMAIL PROTECTED] + * @author Boris Poudérous [EMAIL PROTECTED] * @author Peter Herweg [EMAIL PROTECTED] * @author Andreas Putz [EMAIL PROTECTED] Uh, there shouldn't be any non ascii characters in the java sources. (see http://wiki.apache.org/xmlgraphics-fop/FOPDevelopersStyleGuide, which should make it into the website) And @author tags are discouraged anyway ;-) -- Christian
EMF support for RTF output
Peter, I've had a look at your changes to the RTF output concerning image support. It's cool to see that switching to FOP's image adapters was relatively painless. I've stumbled upon one problem, though. If you run external-graphic_emf.xml through the RTFHandler the image is distorted. It looks like RtfExternalGraphic.computeImageSize() fetches wrong values from the EMF. That's not so important for me right now, but I wanted you to know about it. Jeremias Maerki
Re: Leading/trailing space removal in LineLM
On Sat, 5 Nov 2005 12:05 am, Luca Furini wrote: Manuel Mall wrote: Here are some of the combinations I have identified: 1. Non breaking / non elastic space = probably just a normal character, i.e. part of a word. 2. Non breaking / elastic space - eg. U+00A0 Non breaking space = Must prevent break = Must handle text-align 3. Break / non elastic - eg. U+200B ZWSP, any other break between two characters not involving adding or removing space/characters = Must handle border/padding = Must handle text-align 4. Break / non elastic / remove if not break - eg. U+00AD Soft hyphen = Must remove if not at break = Must handle border/padding = Must handle text-align 5. Break / non elastic / add character if break - eg. hyphenation = Must add space for hyphen if at break = Must handle border/padding = Must handle text-align 6. Breaking / elastic / non removable - eg. U+3000 Ideographic space = Must handle border/padding = Must handle text-align Question: XSL-FO does not define U+3000 as removable white space but would under common CJK typesetting conventions this be removed at a line break? 7. Breaking / elastic / removable - eg. U+0020 Space = Can occur in runs which must be wholly removed = Must handle border/padding = Must handle text-align Any combinations I have missed, e.g. is there a break / non elastic / remove at break case? I moved all this to a Wiki page with the actual Knuth sequences (http://wiki.apache.org/xmlgraphics-fop/LineBreaking). Please review / check! Maybe the fixed width spaces? Yes - may be. Anyway, it seems an exhaustive analysis of the problem! Just a few comments / thoughts: - non breaking, non elastic: the simple solution would be to handle these characters as normal letters, so the text before_after (where _ is zwnbsp) would create a single AreaInfo object in the TextLM; but this would create problems during hyphenation, as non-letter characters in the middle of a word ATM prevents hyphenation I think word breaking, i.e. determining the word boundaries for the purpose of hyphenation, and line breaking are not 100% coupled. There are actually different Unicode documents describing each. Therefore down the track I don't see treating these are normal characters for the purpose of line breaking as being a problem as the word breaking would be done may be in parallel but logically separate. We also most likely want Knuth box elements covering the largest extend of consecutive characters as possible because a) it saves resources and b) as the width of Knuth elements are the basis of determining what fits on a line if we ever look into kerning the calculations would need to be done on a per Knuth box element basis. - soft hyphen: at the moment it is not properly handled, but it won't be difficult to fix the implementation; it could create the same elements used for an hyphenation point, but the penalty could have a negative value (as probably users would use it to suggest a desired line break); note that a word with a soft hyphen in its middle would not be hyphenated, unless we ignore this character when collecting word fragments I thought we simply delete the soft-hyphen character and generate a normal break with hyphen Knuth sequence at that point. Regards Luca Manuel
DO NOT REPLY [Bug 37411] - pdf - generated links in document don't all work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37411. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37411 --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 19:58 --- Created an attachment (id=16914) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16914action=view) the FOP input -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37411] - pdf - generated links in document don't all work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37411. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37411 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 20:14 --- sorry, disregard, I have to test this with the latest changes in the code repository which I thought I had but in fact didn't Set to invalid for now -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37412] - nullpointer exception in ListItemContentLayoutManager.addAreas
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37412. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37412 --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 20:29 --- Created an attachment (id=16916) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16916action=view) the original docbook transformed with docbookxsl -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37412] - nullpointer exception in ListItemContentLayoutManager.addAreas
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37412. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37412 --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 20:29 --- Created an attachment (id=16917) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16917action=view) the FOP input -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37412] - nullpointer exception in ListItemContentLayoutManager.addAreas
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37412. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37412 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Version|all |1.0dev --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 21:48 --- Bug fixed: http://svn.apache.org/viewcvs?rev=331880view=rev Thanks for reporting it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37414] - ant dist does not include fop (nee fop.sh)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37414. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37414 --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 22:51 --- Created an attachment (id=16920) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16920action=view) Patch against build.xml in trunk to include fop -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37415] - java.lang.ClassCastException: org.apache.fop.layoutmgr.PaddingElement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37415. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37415 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37415] - java.lang.ClassCastException: org.apache.fop.layoutmgr.PaddingElement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37415. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37415 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-11-08 23:35 --- Done! Apologies, Manuel, for pointing the finger at you... (I assumed, since you had been busy with padding etc.) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37417] New: - Patch to support fop from partially implemented Class Loaders.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37417.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37417
Summary: Patch to support fop from partially implemented Class
Loaders.
Product: Fop
Version: 1.0dev
Platform: All
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P5
Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
org.apach.fop.Version line 33 (ver 328820) assumes that
Version.class.getPackage() will return the package info of the class however
it may return null if it was loaded from an incomplete class loader that
doesn't implement definePackage correctly by loading the manifest info from
the jar file. Whilst the proper solution is to fix these class loaders it
would be prudent to gracefully handle this situation.
The attached patch attempts to do so.
==START PATCH==
Index: src/java/org/apache/fop/Version.java
===
--- src/java/org/apache/fop/Version.java(revision 331635)
+++ src/java/org/apache/fop/Version.java(working copy)
@@ -30,7 +30,11 @@
* @return the version string
*/
public static String getVersion() {
-String version = Version.class.getPackage().getImplementationVersion
();
+String version = null;
+Package jarinfo = Version.class.getPackage();
+if(jarinfo != null) {
+version = jarinfo.getImplementationVersion();
+}
if (version == null) {
//Fallback if FOP is used in a development environment
String headURL
==END PATCH==
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Re: Leading/trailing space removal in LineLM
On Wed, 9 Nov 2005 12:47 am, Andreas L Delmelle wrote: On Nov 4, 2005, at 17:05, Luca Furini wrote: Hi Manuel / Luca, Manuel Mall wrote: Here are some of the combinations I have identified: snip / 6. Breaking / elastic / non removable - eg. U+3000 Ideographic space = Must handle border/padding = Must handle text-align Question: XSL-FO does not define U+3000 as removable white space but would under common CJK typesetting conventions this be removed at a line break? I think so. That's precisely what the definition for the auto value of suppress-at-line-break warns about. Does this mean that the use of a fo:character is mandated if the user wants it removed? Yes, IMO. Unless the editors can be persuaded to make U+3000 an exception to the default retain, like common spaces (U+0020), compliance means treating this character maybe a bit counter-intuitively. 7. Breaking / elastic / removable - eg. U+0020 Space = Can occur in runs which must be wholly removed = Must handle border/padding = Must handle text-align Any combinations I have missed, e.g. is there a break / non elastic / remove at break case? Maybe the fixed width spaces? More generally: any fixed-width character, added through a fo:character, implying a feasible/favorable break before or after, and having suppress-at-line-break=suppress. I could put: fo:character character=a suppress-at-line-break=suppress / in a document, surrounded by non-collapsible whitespace, and the formatter may decide to break before/after and drop the 'a'. Fixed-width spaces could be viewed as a subset. If they aren't added via a fo:character, they would belong to category 'break - non- elastic - non-removable'. (speaking strictly XSL-FO) Andreas, I tend to disagree with the basic sentiment express here. If we accept Simon's notion that white space handling in XSL-FO is about dealing with spaces and linefeeds introduced by editors or humans for XML readability purposes then dealing with typographic conventions of particular scripts has nothing to do with the rules of white space handling. XSL-FO in quite a few places mentions user agent flexibility when it comes to dealing with script / language / country specific items. If we can, as Joerg suggests, replace a base letter followed by a combining diacritical mark with a matching combined glyph, why can't we replace an ideographic space followed by a line break with simply the line break? The point being I am not suggesting to remove the ideographic space under the XSL-FO white space rules but under 'script specific typographic conventions'. And I believe there is nothing in the spec which prohibits this - quite the opposite actually - the spec IMO encourages 'intelligent' handling of 'local customs'. Of course I don't know what the CJK typographic conventions are so this is all a bit hypothetical. Cheers, Andreas Regards Manuel
Re: Leading/trailing space removal in LineLM
On Wed, 9 Nov 2005 12:32 pm, Andreas L Delmelle wrote: On Nov 9, 2005, at 02:09, Manuel Mall wrote: Manuel, snip/ We're (again) more in agreement than we realize, I think... Although, now you got me wondering what you think is my 'basic sentiment' :-) After reading your post = yes we are once again in agreement. And don't worry about the sentiment stuff - just a minor distraction :-). snip/ Well, I can't find the exact reference (may be one of the earlier posts in this thread), but I seem to remember that the ideographic space can only shrink, not expand. Following that, I would say that there is little difference between suppressing a character, and shrinking it to zero width. Maybe, since it needs to be shrinkable anyway, it could be treated along that line? UAX#14 I think is the reference. snip/ Cheers, Andreas Manuel
