Re: svn commit: r1151195 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java status.xml
See below Peter West How can these things be? On 28/07/2011, at 9:59 PM, Vincent Hennebert wrote: On 27/07/11 13:39, Jeremias Maerki wrote: On 27.07.2011 12:09:58 Vincent Hennebert wrote: So we're back to nitpicking. Oh, absolutely not! I actually find it very worrying that you consider this to be nitpicking, when any decent book about software programming will ... etc. etc. I've done that intentionally to indicate that the variable is only just used by the following method. By putting it at a non-expected place you’re making it difficult to find the variable and understand in a quick glance what the class is made of. This hampers the readability and maintainability of the code. Given that it’s what we spend most of our time on, I find this worrying. That is, by assisting the understanding of the use of this variable, you have made it harder to understand in a quick glance. But in any case... Your needing to put the variable near to the methods that use it is a clear sign that this class is too big and needs to be split into smaller entities. And the null is only there to emphasize that the variable is lazily assigned because the thing is often not even needed. This is an interesting convention, although I believe it is cancelled out by the fact that in a vast majority of cases, the initialization is there just out of ignorance of Java’s default initialization. But that doesn’t matter too much. That is, you're a dope who doesn't understand Java, unlike some. Come clean, Jeremias. makes the method hard to understand and maintain. This method should most probably be split into smaller methods. I'll swallow my comment to this and just do the split: http://svn.apache.org/viewvc?rev=1151447view=rev When I read this and the sarcastic message associated to the commit, I’m concerned about the unwelcoming atmosphere that is being created on this mailing list. Can we try and remain civil to each other? Vincent is concerned that YOU are creating an unwelcome atmosphere on this list. Jeremias, when will you learn? But more importantly, there is no unit test that comes with this commit. So there is no reason to believe that the problem is fixed and, most of all, will not happen again in the future. Can you please add a unit test for this? No, I cannot. For licensing reasons. I can't upload the font that's causing this into the Apache SVN repository. I'd have to artificially construct a font that emulates this and I certainly won't try to do that. We have the DejaVuLGCSerif font in our tests/resources/fonts directory. Surely it must be possible to reproduce the issue with that font. Did you have a look at it? Well, DID you? Eh? Eh? Thanks, Vincent
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
I suppose you have JAI installed in both 6u17 and 6u18/24? Peter West Why do you seek the living among the dead? He is not here, but is risen. On 04/05/2011, at 8:17 PM, Ognjen Blagojevic wrote: Hi, To keep issue alive, I reported a bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=51149 Regards, Ognjen
Re: 20x slowdown in PNG processing when switching from JDK 1.6.0_17 to 1.6.0_18
Ognjen, You may well have it, depending on where you got your Java installation. I see you're on windows, so it's probably already included. With linux, I used to have to install it myself, but I've been using OS X for a while now, so I don't know about either Windows or linux any more. The others will tell you if it's necessary. Peter West Why do you seek the living among the dead? He is not here, but is risen. On 04/05/2011, at 11:24 PM, Ognjen Blagojevic wrote: Hi Peter, I didn't install anything other than regular JDK for Linux. Do you mean JAI library or JAI Image I/O tools? They are both mentioned in FOP docs [1], but from what I understand neither is necessary for PNG image manipulation: (BMP, TIFF) Requires the presence of JAI Image I/O Tools (or an equivalent Image I/O compatible codec) in the classpath. JAI Image I/O Tools also adds support for JPEG 2000, WBMP, RAW and PNM. Other Image I/O codecs may provide support for additional formats.. Do I need to install it, anyway? Regards, Ognjen [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#support-overview
Re: DO NOT REPLY [Bug 50240] New: [PATCH] Upgrade to Java 1.5 - Converted EncodingMode to an Enum
You may find some of the code in the now-stagnant SourceForge Folio project useful. It has lots of enums defined, for example. It is MPL, but just let me know and I'll change the licence. Peter West He said to them, Come and see. On 10/11/2010, at 2:35 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50240 Summary: [PATCH] Upgrade to Java 1.5 - Converted EncodingMode to an Enum Product: Fop Version: all Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: med1...@gmail.com Created an attachment (id=26272) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26272) EncodingMode changed from class - enum In light of the recent vote to convert to Java5, I have changed o.a.f.fonts.EncodingMode.java to an enumerated type. I've also added a JUnit test for this enum. I have tested this enum with various different fonts and diffed them to ensure there are no differences. -- 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: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts: AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java CharacterSetOrientation.java D
I'm puzzled by this discussion. AFAIK, Java has rejected moving to 32 bits in Java 5. Instead, they are supporting supplementary characters. There's a discussion here: http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ Peter West Lord, to whom shall we go? On 21/05/2010, at 11:11 PM, Glenn Adams wrote: I concur with this change, and have already made some changes in this direction in my work on adding complex script support. Please note that it is not quite so simple as merely changing from char to int in some locations. It is also necessary to convert from UTF-16 to UTF-32, i.e., to the full Unicode code point value, which can range from 0x00 through 0x10 (see Unicode 5.2, Section 3.3, Item D9). It is probably not a good idea to make this conversion too early, but rather, to defer it until certain well defined interface points, which need to be documented as taking the full Unicode code point, and not merely a UTF-16 code element. On Fri, May 21, 2010 at 3:46 AM, Vincent Hennebert vhenneb...@gmail.com wrote: Hi, Author: jeremias Date: Thu May 20 09:52:27 2010 New Revision: 946585 URL: http://svn.apache.org/viewvc?rev=946585view=rev Log: Changed many variables and parameters from int to char because AFP font support mostly uses Unicode code points unlike Type 1 and TrueType support which use internal character code points (the result of Font.mapChar()). This should improve code readability. Not sure this is a desirable change. char can only address characters from the Basic Multilingual Plane. Java 1.5 have started to use int to overcome that issue actually. So unless there is a fundamental limitation in AFP such that characters beyond the BMP will never be usable, I think we want to stick to int. snip/ Vincent
Re: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts: AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java CharacterSetOrientation.java Dou
Sorry, I wasn't paying enough attention.
Yes, when dealing with individual character interfaces, you need to provide
codepoint as well as char. The relationship between codepoints and strings is
not straightforward, however.
Peter West
Lord, to whom shall we go?
On 22/05/2010, at 12:14 AM, Glenn Adams wrote:
it's a simple problem, which can be stated as follows:
• the char data type in Java does not denote a character, rather, it
denotes a UTF-16 encoding element
• some Unicode characters, i.e., those in the BMP, are represented by
one char element (char[1]), while other Unicode characters require two char
elements (char[2]);
• in order to make use of non-BMP characters, of which there are now
many standardized instances, one must either pass a char array, e.g.,
char[2], or, alternatively pass an int, which is capable of representing all
Unicode code points in the range of 0 ... 0x10;
at some point, FOP needs to support the effective use of characters outside
the BMP coding space, and, consequently, those FOP interfaces that use the
char type need to be upgraded to int;
I am referring to FOP defined interfaces mind you, not Java defined
interfaces; in general, the Java interfaces provide mechanisms to address
this problem; for instance, see the discussion in the preamble of the
definition of java.lang.Character, the pertinent point of which I repeat
below:
• The methods that only accept a char value cannot support
supplementary characters. They treat char values from the surrogate ranges as
undefined characters. For example, Character.isLetter('\uD840') returns
false, even though this specific value if followed by any low-surrogate value
in a string would represent a letter.
• The methods that accept an int value support all Unicode characters,
including supplementary characters. For example, Character.isLetter(0x2F81A)
returns truebecause the code point value represents a letter (a CJK
ideograph).
what I believe the original commenter is pointing out (and that I am agreeing
with) is that FOP needs to take care to not use the char type for interface
parameters that are intended to denote a Unicode character; or, if they do,
then an overloaded version of the same interface that uses the int type
should also be provided;
for example, the following interfaces need to be upgraded to int or to have
an overloaded int variant:
org.apache.fop.fonts.Font.getKernValue(char ch1, char ch2);
org.apache.fop.fonts.Font.getWidth(char charnum);
org.apache.fop.fonts.Font.mapChar(char c);
org.apache.fop.fonts.Font.hasChar(char c);
org.apache.fop.fo.CharIterator.replaceChar(char c);
org.apache.fop.fo.flow.Character.getCharacter();
org.apache.fop.util.CharUtilities.*;
...
i have already upgraded al of the CharUtilities.* methods to use int instead
of char in my present work on complex script support, but there are a variety
of other internal interfaces as noted above that need to be upgraded as well.
if you like, I can fold this into my present work, or assign it a new bug
number (which may be the best for tracking purposes);
regards,
glenn
On Fri, May 21, 2010 at 7:31 AM, Peter B. West li...@pbw.id.au wrote:
I'm puzzled by this discussion. AFAIK, Java has rejected moving to 32 bits in
Java 5. Instead, they are supporting supplementary characters. There's a
discussion here:
http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
Peter West
Lord, to whom shall we go?
On 21/05/2010, at 11:11 PM, Glenn Adams wrote:
I concur with this change, and have already made some changes in this
direction in my work on adding complex script support.
Please note that it is not quite so simple as merely changing from char to
int in some locations. It is also necessary to convert from UTF-16 to
UTF-32, i.e., to the full Unicode code point value, which can range from
0x00 through 0x10 (see Unicode 5.2, Section 3.3, Item D9). It is
probably not a good idea to make this conversion too early, but rather, to
defer it until certain well defined interface points, which need to be
documented as taking the full Unicode code point, and not merely a UTF-16
code element.
On Fri, May 21, 2010 at 3:46 AM, Vincent Hennebert vhenneb...@gmail.com
wrote:
Hi,
Author: jeremias
Date: Thu May 20 09:52:27 2010
New Revision: 946585
URL: http://svn.apache.org/viewvc?rev=946585view=rev
Log:
Changed many variables and parameters from int to char because AFP
font support mostly uses Unicode code points unlike Type 1 and TrueType
support which use internal character code points (the result of
Font.mapChar()). This should improve code readability.
Not sure this is a desirable change. char can only address characters
from the Basic Multilingual Plane. Java 1.5 have started to use int to
overcome that issue actually. So
Re: Initial Values of Variables [was: Re: svn commit: r825875 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java]
Yep, they sure are. Does it hurt to spell it out? Like redundant parentheses, it does no harm, and makes the code just that little bit more explicit, for the dodos like me. Peter On 20/10/2009, at 8:13 PM, Vincent Hennebert wrote: Hi, Just a nit: +private boolean useCatalogResolver = false; +private EntityResolver entityResolver = null; +private URIResolver uriResolver = null; Those fields are being initialized to their default values. The Java Language Specification states [1] that every field must be initialized with a default value, basically 0 for numbers, false for booleans, and null for objects. So explicitly initializing them with their default values is just noise. I’d like to suggest everyone to remove those unnecessary initializations in the future. [1] http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.5 Thanks, Vincent
Re: ambiguity of grammar for font shorthand?
On 23/09/2009, at 8:18 PM, Vincent Hennebert wrote: Hi Tony, Tony Graham wrote: On Mon, Sep 21 2009 23:30:17 +0100, jonathan.levin...@intersystems.com wrote: ... If inherit is allowed to be a value then the grammar truly becomes ambiguous since each of these can have the value inherit and we don?t know which ones are omitted and must take the value normal. 'inherit' doesn't mix with other values [1]. AFAIK, this is true even for shorthands taken from CSS2. Well the point you’re referring to says that ‘inherit’ can’t be mixed with other operations in an expression. Technically speaking the shorthand is not an expression. And, anyway, the point also says that the ‘from-parent()’ function can be used instead, which leads to the same issue. That said, your point made me look at the introduction of section 7.31, “Shorthand Properties”: http://www.w3.org/TR/2006/REC-xsl11-20061205/#d0e33965 which says that “One cannot mix ‘inherit’ with other subproperty values as it would not be possible to specify the subproperty to which ‘inherit’ applied”. While this is not always true as we found out, that avoids the problem... When is it not true? ... Except when the ‘normal’ keyword is used, which applies to all three style/variant/weight properties, and may also lead to ambiguous values. Font shorthand implicitly sets _all_ of these values to normal, doesn't it? If the value is 'inherit', the individual properties for which the shorthand is a shorthand individually inherit [2]. Regards, Tony Graham tony.gra...@menteithconsulting.com Director W3C XSL FO SG Invited Expert Menteith Consulting Ltd XML Guild member XML, XSL and XSLT consulting, programming and training Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland Registered in Ireland - No. 428599 http:// www.menteithconsulting.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- xmlroff XSL Formatter http:// xmlroff.org xslide Emacs mode http://www.menteith.com/wiki/ xslide Unicode: A Primer urn:isbn: 0-7645-4625-2 [1] http://www.w3.org/TR/xsl11/#d0e5479 [2] http://www.w3.org/TR/xsl11/#shortexpan Vincent
Re: ambiguity of grammar for font shorthand?
On 23/09/2009, at 12:13 AM, Jonathan Levinson wrote: Hi Vincent, You make excellent points, however for font-style, font-variant and font-weight the initial value (the default value) is normal, not inherit. http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#font-style http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#font-variant http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#font-weight This is a minor detail, but important if our discussion is used as the basis for building a recursive descent parser. An important detail. When the font shorthand is encountered, all font properties (including those that cannot be defined in the shorthand) are set to their initial values.
Re: Moving to Java 1.5, retroweaving for 1.4
On 03/09/2009, at 6:51 PM, Max Berger wrote: Dear Fop Devs, Peter B. West schrieb: Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit machines. Apple's commitment to Java has slackened off considerably. Peter Just for the mail archives: Snow Leopard (Mac OS X 10.6) includes Java 6 on 32-bit intel architectures [and was not yet released at the time of the original post]. Thanks Max. Very good news. Peter
Re: Moving to Java 1.5, retroweaving for 1.4
On 24/08/2009, at 10:04 PM, Laurent Caillette wrote: Hi all, A few thoughts about Java 1.5 support and FOP version numbers. I suggest to keep the emblematic 1.0 for the full support of the XSLT-1.0 spec. I don't see any problem with FOP version hitting 0.99 or even 0.123 one day. Java 5 as minimum requirement sounds good to me (while another version with 1.4 sounds reasonable, too). But Java 6 is too high as minimum requirement. Java 5 is still the default JVM on Mac. Hope this helps, c. Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit machines. Apple's commitment to Java has slackened off considerably. Peter
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
On 20/08/2009, at 7:41 PM, Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/ Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/ Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isTitleCase/(I)Z, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toLowerCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method getType/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in java.lang.Character$Unicod eBlock [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toUpperCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toTitleCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter: unknown class javax.crypto.CipherOutputStream [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method doFinal/([B)[B, The class, javax.crypto.Cipher, could not be located: javax/crypto/Cipher [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.IllegalBlockSizeException, could not be located: javax/crypto/IllegalBlockSizeException [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class,
Re: FOPIDESetupGuide updated to Netbeans 6.5
Andreas Delmelle wrote: On 21 Jan 2009, at 11:45, Peter B. West wrote: It might be a good idea to set svn:ignore properties on ant.jar and the offo jars in lib. Then you could tell interested parties to drop those jars into lib as part of the preparation for building, and it's unlikely that the jars will come back t haunt you. Yep, dropping the ant.jar in $FOP_HOME$/lib would probably be the fastest solution. It's what I wanted to suggest first, but then again, I'm personally not too fond of copying JARs around. If you have Ant somewhere on your machine, then IMO, it's cleaner to have the build-classpath point to that ant.jar than copying it to the lib folder. Just remembered: we have svn:ignore set on the file $FOP_HOME/build-local.properties, which one could create and use to specify locations of dependencies that are dependent on the local setup. If you're running *n*x, you can link ant.jar into lib. I believe you can even do that with ntfs nowadays. It's simpler to have all your build requirements in one place. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/folio.html
Re: FOPIDESetupGuide updated to Netbeans 6.5
I was interested to read the procedure outlined, but I think there is a slightly easier way, using what NetBeans calls Free-Form Projects. When I get a bit of time, I'll put some detail son the wiki. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/folio.html
Re: FOPIDESetupGuide updated to Netbeans 6.5
Andreas Delmelle wrote: On 19 Jan 2009, at 13:42, Ulrich Mayring wrote: Hi Ulrich Ulrich Mayring wrote: Peter B. West wrote: You must set up hyphenation from the OFFO site. http://offo.sourceforge.net/hyphenation/ Ok thanks, the build works now. Maybe the SetupGuide could be updated to mention that this has to be done before the first ant build. Duh... strange. At first the build worked, but now it doesn't, there is a package org.apache.tools.ant missing. When do you get this message exactly? FOP depends on Ant for the anttask (org.apache.fop.tools.*), and this is one dependency that we do not include in the distribution. So you'll have to make sure that ant.jar is somewhere in the classpath that is used when compiling the FOP sources. You could set the 'optional.lib.dirs' property in $FOP_HOME$/build.properties to include the path to ant.jar on your machine. HTH! Cheers Andreas It might be a good idea to set svn:ignore properties on ant.jar and the offo jars in lib. Then you could tell interested parties to drop those jars into lib as part of the preparation for building, and it's unlikely that the jars will come back t haunt you. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/folio.html
Re: Configuring Netbeans - missing org.apache.fop.fonts
Jeremias Maerki wrote: Well, using the CLASSPATH env variable begs for trouble. I consider it a mistake of Java 1.0 that has been carried on until today. Good thing you found the problem. BTW, Peter, are you aware that the Folio website reports an error? I wasn't aware of that, thanks. Which page? I can't see a problem in firefox on linux or mac, or on safari. Peter
Re: Configuring Netbeans - missing org.apache.fop.fonts
Jeremias Maerki wrote: I have no idea what's going wrong. It seems to work for everyone else. In my log output with Ant 1.7 and the -d option I get different log output. For example, Ant includes the full classpath for the javac task in the resourcegen target which doesn't seem to happen on your end. But unfortunately, Ant doesn't log the effective classpath for the taskdef task at all, not even the setup of the libs-build-classpath and libs-build-tools-classpath early in build.xml which are used by the taskdef. What does ant init spit out? Have you checked for permission problems on the JAR files in the lib directory? Shrug. The problem was an older version of fop.jar on the CLASSPATH. That is, the build is, at some point, dependent on the CLASSPATH, which doesn't seem to be a good idea. Peter
Re: Configuring Netbeans - missing org.apache.fop.fonts
Jeremias Maerki wrote:
That's weird. It works for me (well, I'm not using NetBeans) and for
Gump, too. Line 355, that's the eventResourceGenerator for the event
processing stuff. That task uses the normal classpaths set up for FOP:
all JARs (*.jar) in lib and lib/build plus some compiled classes in the
build directory. I don't assume you've manipulated the basedir
property because that would probably have led to problems earlier in the
script. I'd run the Ant script with -d or -v to see what's going on.
On 24.12.2008 01:36:08 Peter B. West wrote:
Yes, I know. When I checkout I get a lib directory with
xmlgraphics-commons-1.4svn. I make no changes. When I then build with
ant clean; ant package
BUILD FAILED
/home/pbw/NetBeansProjects/fop-trunk/build.xml:355:
java.lang.NoClassDefFoundError: org/apache/xmlgraphics/util/XMLizable
I tried linking xmlgraphics-commons-1.4svn to xmlgraphics-commons.jar,
but it makes no difference.
Peter
Jeremias Maerki wrote:
XMLizable is in xmlgraphics-commons.jar.
On 23.12.2008 05:19:25 Peter B. West wrote:
I just tried to do a clean checkout, build and create a NetBeans project.
Form a previous experience, I put ant.jar. qdox.jar and XMLUnit.jar in
the lib directory, and tried to build 'package' from the command line.
Got a class not found fro XMLizable in one of the event producer tasks.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Jeremias,
Still failing with revision 735275.
Here's the tail of 'ant -d jar-main'.
resourcegen:
[mkdir] Skipping
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes because
it already exists.
fileset: Setup scanner in dir
/home/pbw/NetBeansProjects/fop-trunk/trunk/src/codegen/java with
patternSet{ includes: [**/*.java] excludes: [] }
[javac] org/apache/fop/tools/EventConventionException.java omitted
as
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes/org/apache/fop/tools/EventConventionException.class
is up to date.
[javac] org/apache/fop/tools/EventProducerCollector.java omitted as
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes/org/apache/fop/tools/EventProducerCollector.class
is up to date.
[javac] org/apache/fop/tools/EventProducerCollectorTask.java omitted
as
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes/org/apache/fop/tools/EventProducerCollectorTask.class
is up to date.
fileset: Setup scanner in dir
/home/pbw/NetBeansProjects/fop-trunk/trunk/src/codegen/java with
patternSet{ includes: [**/*.xsl] excludes: [] }
[copy] org/apache/fop/tools/merge-translation.xsl omitted as
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes/org/apache/fop/tools/merge-translation.xsl
is up to date.
[copy] org/apache/fop/tools/model2translation.xsl omitted as
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes/org/apache/fop/tools/model2translation.xsl
is up to date.
[copy] No sources found.
fileset: Setup scanner in dir
/home/pbw/NetBeansProjects/fop-trunk/trunk/lib/build with patternSet{
includes: [*.jar] excludes: [] }
Finding class org.apache.fop.tools.EventProducerCollectorTask
Loaded from
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes
org/apache/fop/tools/EventProducerCollectorTask.class
Class org.apache.tools.ant.Task loaded from parent loader (parentFirst)
Class org.apache.fop.tools.EventProducerCollectorTask loaded from ant
loader (parentFirst)
Class java.lang.Object loaded from parent loader (parentFirst)
Class java.lang.Throwable loaded from parent loader (parentFirst)
Class java.io.IOException loaded from parent loader (parentFirst)
Finding class org.apache.fop.tools.EventConventionException
Loaded from
/home/pbw/NetBeansProjects/fop-trunk/trunk/build/codegen-classes
org/apache/fop/tools/EventConventionException.class
Class java.lang.Exception loaded from parent loader (parentFirst)
Class org.apache.fop.tools.EventConventionException loaded from ant
loader (parentFirst)
Class java.lang.ClassNotFoundException loaded from parent loader
(parentFirst)
Class org.apache.tools.ant.BuildException loaded from parent loader
(parentFirst)
Class org.apache.tools.ant.types.selectors.FileSelector loaded from
parent loader (parentFirst)
Class org.apache.tools.ant.Project loaded from parent loader (parentFirst)
Class java.util.List loaded from parent loader (parentFirst)
Class javax.xml.transform.TransformerException loaded from parent loader
(parentFirst)
Class java.io.FileNotFoundException loaded from parent loader (parentFirst)
Class javax.xml.transform.Source loaded from parent loader (parentFirst)
Class javax.xml.transform.Result loaded from parent loader (parentFirst)
Class java.io.OutputStream loaded from parent loader (parentFirst)
Class java.io.FileOutputStream loaded from parent loader (parentFirst)
Class java.io.BufferedOutputStream loaded from parent loader (parentFirst)
Class javax.xml.transform.URIResolver loaded from parent loader
Re: Configuring Netbeans - missing org.apache.fop.fonts
I just tried to do a clean checkout, build and create a NetBeans project. Form a previous experience, I put ant.jar. qdox.jar and XMLUnit.jar in the lib directory, and tried to build 'package' from the command line. Got a class not found fro XMLizable in one of the event producer tasks. Manuel Mall wrote: Fop has some generated source files which the ant build creates. Run your ant build first then add the generated sources (build/gensrc) to NetBeans as a second source directory. See also http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide. Manuel -Original Message- From: bonekrusher [mailto:djs...@yahoo.com] Sent: Monday, 22 December 2008 9:17 PM To: fop-dev@xmlgraphics.apache.org Subject: Configuring Netbeans - missing org.apache.fop.fonts Hi, Hope you may help me out. I am configuring netbeans 6.5 with the latest FOP trunk. I am getting an import error for the following: import org.apache.fop.fonts.*; and import javax.media.* However, I am able to do a clean build in ant. How can I resolve these in netbeans? Thanks, Phil -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Memory Leak in PropertyCache: need ideas
Jeremias Maerki wrote: Ok, here's the final patch I'd propose to fix the memory leak. I've seen no measurable performance degradation compared to the base revision and no multi-threading problems. The memory leak is fixed and the number of stale references remains low. Feedback welcome. What happens is SEGMENT_COUNT is not a power of 2? Or, what obliges SEGMENT_COUNT to be a power of 2? Peter
Re: Memory Leak in PropertyCache: need ideas
Jeremias Maerki wrote: There's a lot of AND-ing of hash codes to determine the segments and buckets and that's much easier to handle if you have a power of 2 and can shift bits around. On 22.08.2008 16:22:05 Peter B. West wrote: Jeremias Maerki wrote: Ok, here's the final patch I'd propose to fix the memory leak. I've seen no measurable performance degradation compared to the base revision and no multi-threading problems. The memory leak is fixed and the number of stale references remains low. Feedback welcome. What happens is SEGMENT_COUNT is not a power of 2? Or, what obliges SEGMENT_COUNT to be a power of 2? Peter That was my assumption when I saw 'MASK', in which case is it not safer to ensure that your value is in fact all ones? MASK_BIT_COUNT = 5 SEGMENT_COUNT = 1MASK_BIT_COUNT or some such.
Re: Building FOP Trunk with Any - BUILD FAILED
Bones wrote: In the end, I got it working by making sure that the build process was using the exact same XML parser and XSLT processor that were distributed with FOP. - How do I do that with in ant? You're doing it. It's controlled by the classpath set up by ant, which looks pretty straightforward. All the jars in lib and lib/build + the codegen classes. So something very odd is going on. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
Peter B. West wrote: Bones wrote: In the end, I got it working by making sure that the build process was using the exact same XML parser and XSLT processor that were distributed with FOP. - How do I do that with in ant? You're doing it. It's controlled by the classpath set up by ant, which looks pretty straightforward. All the jars in lib and lib/build + the codegen classes. So something very odd is going on. D'uh -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
It looks suspiciously like this guy:
C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xml
(Line 353 btw)
It would be nice to see what is actually being passed into the
eventResourceGenerator task.
bonekrusher wrote:
Peter,
Which file is this?
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
Phil
Peter B. West wrote:
bonekrusher wrote:
I will test this out later today on my home PC. I get a different set of
errors on different machines.
In the mean time I ran a new svn check out (as you suggested) on my work
PC
and got the same original error message e.g.
BUILD FAILED
C:\foptrunk2\trunk\build.xml:353: java.io.IOException:
java.io.FileNotFoundExcep
tion:
file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm
l (The filename, directory name, or volume label syntax is incorrect)
So its seems I have two different problems. I thought I might be doing
something fundamentally wrong, but I was able to build FOP 0.94.
As Jeremias suggested, I will try to download the trunk again from my
home
PC. I don't want to confuse the error reports from one machine to
another
as they appear to be different.
Well, it's incorrect URL syntax. Presumably
${build.gensrc.dir}/org/apache/fop/events/event-model.xml
(see line 353) is being passed in as a file path, not a URL.
Put
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
In any case, it seems to be getting converted into a badly formed file:
URL within the ant task.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: java.nio.CharBuffer
Andreas Delmelle wrote:
On Jul 14, 2008, at 18:15, Andreas Delmelle wrote:
snip /
Just quickly ran Jeremias' test-app myself, and on Apple JVM (1.5), the
difference is +/-300ms for a million iterations, but not very
consistent. Sometimes StringBuffer operates slightly faster, other times
it's CharBuffer that wins. I guess the backing implementations are very
closely related anyway, so it's not all that surprising.
It would most definitely be a huge overkill if it is /only/ used for
simple String concatenation. In the context of catching SAX characters()
events, I think the penalty is bound to be limited (maybe even on the
contrary: see below). That is, I don't think I've ever seen a parser
that reports characters one at a time (which would make the current
implementation using CharBuffer very slow). Most SAX parsers report the
characters in reasonably large chunks (as much as possible).
Just for fun, make it:
...
private static final char[] prefix = {' ', 'm', 'y', 'V', 'a', 'l', 'u',
'e', '='};
...
public String runCharBuffer() {
CharBuffer buf = CharBuffer.allocate(1024);
for (int i = 0; i STEPS; i++) {
buf.put(prefix).put(Integer.toString(i).toCharArray());
}
return buf.rewind().toString();
}
...
On my end, this runs noticeably faster than when passing Strings (almost
20%). When switching StringBuffer.append() to use char[] parameters, it
runs a tiny bit slower than with Strings... No idea if this also holds
for the Sun, IBM or Apache implementations.
Qua flexibility, the API for a CharBuffer (optionally) offers the
possibility to get a reference to the backing array. For StringBuffer,
we'd have to do something like: sb.toString().toCharArray(), and IIC,
this always yields an independent copy of the StringBuffer's array, not
the array itself. (Note that this obviously also has its drawbacks;
sometimes, you just /need/ an independent copy...)
Come 1.5, you get StringBuilder.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
bonekrusher wrote:
I will test this out later today on my home PC. I get a different set of
errors on different machines.
In the mean time I ran a new svn check out (as you suggested) on my work PC
and got the same original error message e.g.
BUILD FAILED
C:\foptrunk2\trunk\build.xml:353: java.io.IOException:
java.io.FileNotFoundExcep
tion:
file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm
l (The filename, directory name, or volume label syntax is incorrect)
So its seems I have two different problems. I thought I might be doing
something fundamentally wrong, but I was able to build FOP 0.94.
As Jeremias suggested, I will try to download the trunk again from my home
PC. I don't want to confuse the error reports from one machine to another
as they appear to be different.
Well, it's incorrect URL syntax. Presumably
${build.gensrc.dir}/org/apache/fop/events/event-model.xml
(see line 353) is being passed in as a file path, not a URL.
Put
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
In any case, it seems to be getting converted into a badly formed file:
URL within the ant task.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
bonekrusher wrote: Ok, I wanted to test this at home to see if this was a machine issue. Tested on: Windows XP sp2 Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b12) Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing) I am still unable to build with ant. I get another set of errors. I will email Jeremias the out.txt file. I also tried the the version (src/java/org/apache/fop/events/model/EventModel.java) posted, but got a bunch of errors. I will send that report to. Bones What does ant -version tell you? How do you find out which command is being executed in Windows? In linux, you execute which ant or type ant Can you do the equivalent on your system. Can you list the files and file sizes of lib and lib/build? -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
bonekrusher wrote: Ok I ran the build under three versions of ant: Apache Ant version 1.6.5 compiled on June 2 2005 Apache Ant version 1.7.0 compiled on December 13 2006 Apache Ant version 1.7.1 compiled on June 27 2008 All failed. To rule out ant, I downloaded FOP 0.94 src and ran a successfully build. This would leave me to believe that the problem lies in the trunk version. Bones. You've found a real head-scratcher. I've just done an update on fop, and run a clean, followed by package. I don't generally run the tests. The build was OK. H Can you look at the lib differences between 0.94 and trunk? -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java
Jeremias Maerki wrote: On 12.07.2008 14:49:03 Andreas Delmelle wrote: On Jul 12, 2008, at 14:19, [EMAIL PROTECTED] wrote: Author: jeremias Date: Sat Jul 12 05:19:40 2008 New Revision: 676161 URL: http://svn.apache.org/viewvc?rev=676161view=rev Log: Attempt to fix a potential build problem. FWIW, I've locally replaced all occurrences of File.toURL() in the codebase to File.toURI().toURL(). Once I've confirmed this breaks no tests, I'll commit the changes, so this is out of the way. Thanks a lot. Going through the occurrences, I'm getting the impression that in some cases, we don't even really need the URL. The URI would do just fine if we don't need the functionality for opening a stream... Maybe in this particular case, passing through a URL could also be avoided (?) If the error is generated by the used StreamResult implementation calling File.toURL(), then something like: Result res = new StreamResult(outputFile.toURI().toASCIIString()); would already be enough (?) In most cases, yes. But there's really a difference between a URI and a URL. But what's confusing is the following (the Javadocs for StreamSource): quote public StreamSource(String systemId) Construct a StreamSource from a URL. Parameters: systemId - Must be a String that conforms to the URI syntax. /quote URL and URI are both used here. But I think URL is the mandatory term here. The other thing is URI Syntax which does not refer to URI itself. Since a URL is a URI, but not all URIs are URLs, I believe your example above is slightly incorrect. Jeremias Maerki It's a SystemId. The class includes setSystemId(...) and setPublicId(...), so a URL looks right. One way to find out. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java
I can recommend it. Max Berger wrote: Vincent, it may (or may not) make sense to move to commons-cli: http://commons.apache.org/cli/introduction.html which addresses this (and other problems) very well, but this would mean a lot more work. Max -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: svn commit: r670341 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FONode.java FOText.java FOTreeBuilder.java FObjMixed.java
Andreas Delmelle wrote: On Jul 9, 2008, at 09:39, Peter B. West wrote: Jeremias Maerki wrote: Am I the only one concerned about backwards-compatibility here? It's not my *concern*, but deliberately breaking compatibility does seem pretty silly. Yeah, so one night I thought: Let's see if we can annoy everyone who has the bad habit of not using the readily provided base classes for extensions... :- Cheers Andreas That explains it! -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: [OT] [EMAIL PROTECTED]
Jeremias Maerki wrote: I just noticed that Ohloh finally shows FOP's full code history. The project cost now also shows a somewhat more realistic value. http://www.ohloh.net/projects/fop/analyses/latest Jeremias Maerki Measuring this stuff is a very tricky business. On trunk alone, following a clean, run the following: find . -name .svn -prune -o -type f -name '*.java' -print|while read file; do cat $file;done|wc Result: 424558 1611465 15146740 find . -name .svn -prune -o -name '*.xml' -o -name '*.xsl' -o -name '*.xsd' -o -name '*.fo' -print|while read file; do cat $file;done|wc Result: wc: standard input:69950: Invalid or incomplete multibyte or wide character (numerous repetitions - Linux is Unicode) 82258 296838 3808137 I may have forgotten some important categories of xml file here, and it doesn't include the website or active development branches. I couldn't understand all of that xml. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
bonekrusher wrote: Hi, I am trying to build the FOP trunk (checked out with svn) with Ant and get the following error: va:231: warning: [deprecation] toURL() in java.io.File has been deprecated [javac] urls.add(libFiles[i].toURL()); [javac] ^ [javac] 26 warnings [mkdir] Created dir: C:\fop_trunk\trunk\build\sandbox-classes [javac] Compiling 11 source files to C:\fop_trunk\trunk\build\sandbox-classe s resourcegen: [mkdir] Created dir: C:\fop_trunk\trunk\build\codegen-classes [javac] Compiling 3 source files to C:\fop_trunk\trunk\build\codegen-classes [copy] Copying 2 files to C:\fop_trunk\trunk\build\codegen-classes BUILD FAILED C:\fop_trunk\trunk\build.xml:353: java.io.IOException: java.io.FileNotFoundExcep tion: file:\C:\fop_trunk\trunk\build\gensrc\org\apache\fop\events\event-model.xm l (The filename, directory name, or volume label syntax is incorrect) Total time: 33 seconds *** The C:\fop_trunk\trunk\build\gensrc\org\apache\fop\events folder is empty. Any thoughts:? What have you got in lib/build? Have you done an update recently? Fop's build environment - which has always been challenging - just gets weirder and weirder. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: DO NOT REPLY [Bug 40798] page-position=last doesn' t work for 1 page document
[EMAIL PROTECTED] wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=40798
...
I haven't gone back to the spec or the code, but assuming 1) that an
only page is also both first and last, and 2) that isOnlyPage tells the
truth about the page being tested, the problem seems to be with the
if (isOnlyPage) {...}
test. Shouldn't it be
if (isOnlyPage) {
if ( ! ( pagePosition == EN_ONLY
|| pagePosition == EN_FIRST
|| pagePosition == EN_LAST ) ) {
return false;
}
--- Comment #7 from Dave Gerdt [EMAIL PROTECTED] 2008-07-08 13:59:23 PST ---
Looking for a solution to this first page/last page problem I found a potential
solution written by Ken Holman [1]. I assumed because he used it (and he seems
to know a little about the subject ;) ) I had found my solution. (I hadn't
discovered this bug yet...)
However, the solution he provides doesn't work with FOP because as Simon points
out above ConditionalPageMasterReference.isValid(isOddPage, isFirstPage,
isLastPage,isBlankPage) ... says explicitly that a conditional pagemaster
reference with page-position=last is not valid for a first page. Looking at
the spec [2][3] I can't see any reason why that should be the case, though I'm
no expert in the spec, to be sure. Can one of the devs comment on this?
As a fix, I reordered the if statement in
ConditionalPageMasterReference.isValid so that the block for isLastPage comes
before the block for isFirstPage and removed 'return false' when pagePosition
== EN_FIRST in the isLastPage block (see code below). This appears to fix the
problem, at least for Ken's test file. Anyone see where this might blow up in
my face somewhere else? I ran the test suite and everything seemed to come out
fine.
The test case is attached.
[1] http://services.renderx.com/lists/xep-support/3856.html
[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_repeatable-page-master-alternatives
[3] http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#page-position
Reordered 'if' from ConditionalPageMasterReference.isValid:
==
if (isOnlyPage) {
if (pagePosition != EN_ONLY) {
return false;
}
} else if (isLastPage) {
if (pagePosition == EN_REST) {
return false;
} else if (pagePosition == EN_FIRST) {
//return false;
}
} else if (isFirstPage) {
if (pagePosition == EN_REST) {
return false;
} else if (pagePosition == EN_LAST) {
return false;
}
} else {
if (pagePosition == EN_FIRST) {
return false;
} else if (pagePosition == EN_LAST) {
return false;
}
}
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: DO NOT REPLY [Bug 40798] page-position=last doesn' t work for 1 page document
Ok. In that case, isOnlyPage is equivalent to
(startPageOfPageSequence == index) isLastPage
and then either replace the 'false' in the getSimplePageMaster call with
that expression, or replace
if (isOnlyPage)
with
if (isFirstPage isLastPage)
Will either of these work with the rest of the code?
David Gerdt wrote:
I would agree with premise 1, but 2 is incorrect I believe. I don't have my
proper development environment in front of me at the moment, but I believe you
can trace the calls used to reach isValid back to PageProvider.cacheNextPage
where you will find code like:
SimplePageMaster spm = pageSeq.getNextSimplePageMaster(
index, (startPageOfPageSequence == index), isLastPage,
false, isBlank);
You can see that isOnlyPage is simply passed as a false. I believe this is just a forward
thinking move on the part of the developer preparing for XSL 1.1's
page-position=only. This attribute is not supported in XSL 1.0. I think they
just went ahead and built the framework to support it, but it is not actually implemented
yet.
Peter B. West [EMAIL PROTECTED] 07/08/08 6:23 PM
[EMAIL PROTECTED] wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=40798
...
I haven't gone back to the spec or the code, but assuming 1) that an
only page is also both first and last, and 2) that isOnlyPage tells the
truth about the page being tested, the problem seems to be with the
if (isOnlyPage) {...}
test. Shouldn't it be
if (isOnlyPage) {
if ( ! ( pagePosition == EN_ONLY
|| pagePosition == EN_FIRST
|| pagePosition == EN_LAST ) ) {
return false;
}
--- Comment #7 from Dave Gerdt [EMAIL PROTECTED] 2008-07-08 13:59:23 PST ---
Looking for a solution to this first page/last page problem I found a potential
solution written by Ken Holman [1]. I assumed because he used it (and he seems
to know a little about the subject ;) ) I had found my solution. (I hadn't
discovered this bug yet...)
However, the solution he provides doesn't work with FOP because as Simon points
out above ConditionalPageMasterReference.isValid(isOddPage, isFirstPage,
isLastPage,isBlankPage) ... says explicitly that a conditional pagemaster
reference with page-position=last is not valid for a first page. Looking at
the spec [2][3] I can't see any reason why that should be the case, though I'm
no expert in the spec, to be sure. Can one of the devs comment on this?
As a fix, I reordered the if statement in
ConditionalPageMasterReference.isValid so that the block for isLastPage comes
before the block for isFirstPage and removed 'return false' when pagePosition
== EN_FIRST in the isLastPage block (see code below). This appears to fix the
problem, at least for Ken's test file. Anyone see where this might blow up in
my face somewhere else? I ran the test suite and everything seemed to come out
fine.
The test case is attached.
[1] http://services.renderx.com/lists/xep-support/3856.html
[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_repeatable-page-master-alternatives
[3] http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#page-position
Reordered 'if' from ConditionalPageMasterReference.isValid:
==
if (isOnlyPage) {
if (pagePosition != EN_ONLY) {
return false;
}
} else if (isLastPage) {
if (pagePosition == EN_REST) {
return false;
} else if (pagePosition == EN_FIRST) {
//return false;
}
} else if (isFirstPage) {
if (pagePosition == EN_REST) {
return false;
} else if (pagePosition == EN_LAST) {
return false;
}
} else {
if (pagePosition == EN_FIRST) {
return false;
} else if (pagePosition == EN_LAST) {
return false;
}
}
nbproject including global 'run' and single-file 'run' and 'debug' targets
For NetBeans 6.1. Attached is a gzipped nbproject directory including ide-targets.xml and ide-file-targets.xml. ide-targets.xml includes a 'run-nb' target for running a transform with an arbitrary set of arguments. This target is associated with the project 'run' menu item in the project.xml file. Also included is ide-file-targets.xml, which includes targets which allow running a selected file,and debugging a selected file. These targets currently only make sense when org.apache.fop.cli.Main is the selected file. These targets are also associated with appropriate menu items in project.xml. All targets depend on any necessary arguments being set as the properties arg0..arg9. arg0 must be set for the targets to execute. The other args are optional. I use these by setting the targets in build-local.properties, an example of which is also attached. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ nbproject.tgz Description: application/compressed-tar ## This is a template for settings which are useful to be ## overridden in a developer specific property files. ## Copy this to build-local.properties, uncomment and change ## properties which should be overridden. ## The file buil-local.properties is not stored in the code ## repository and ignored for file adds. ## === ## 1. Path settings ## All Jars from the optional lib directory are added used for ## compilation and JUnit tests. Put your jars for additional ## dependencies and tools here. # optional.lib.dir = /home/bart/java/lib ## Checkstyle home directory. This is meant to be the top level of the ## checkstyle binary distribution. # checkstyle.home.dir = /home/bart/stuff/checkstyle-4.0-beta6 ## === ## 2. Switches for common tasks ## Javac switches # javac.debug = on # javac.optimize = off # javac.deprecation = on # javac.source = 1.4 # javac.target = 1.4 # javac.fork = on ## JUnit task switches # junit.fork = on ## Packages to produce javadoc. ## Add packages for FOP extensions if necessary. # javadoc.packages = org.apache.fop.*,fopextension.* ## === ## 3. FOP specific properties ## Specify an alternate file that contains a list of disabled layout ## engine tests. # layoutengine.disabled = test/layoutengine/disabled-testcases.txt ## Specify an alternate directory to scan for user supplied ## hyphenation pattern files. # user.hyph.dir = /home/bart/offo arg0 = -c arg1 = fop.xconf.xml arg2 = examples/simple.fo arg3 = simple.pdf arg4 = arg5 = arg6 = arg7 = arg8 = arg9 =
Re: nbproject including global 'run' and single-file 'run' and 'debug' targets
Peter B. West wrote: For NetBeans 6.1. Attached is a gzipped nbproject directory including ide-targets.xml and ide-file-targets.xml. ide-targets.xml includes a 'run-nb' target for running a transform with an arbitrary set of arguments. This target is associated with the project 'run' menu item in the project.xml file. Also included is ide-file-targets.xml, which includes targets which allow running a selected file,and debugging a selected file. These targets currently only make sense when org.apache.fop.cli.Main is the selected file. These targets are also associated with appropriate menu items in project.xml. All targets depend on any necessary arguments being set as the properties arg0..arg9. arg0 must be set for the targets to execute. The other args are optional. I use these by setting the targets in build-local.properties, an example of which is also attached. ... by setting the properties... -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: PageAndLineBreaking/UnifiedApproach
Simon Pepping wrote: ... The fact that the prototype is written in Ruby does not help. I have never worked with Ruby before, so I have to get used to new syntax. More importantly, I do not have good tools for Ruby. When I try to understand code, I do not only read it. I also make extensive use of a debugger. This allows me to see what the code actually does to variables, in this case e.g. how the code fills the various layouts variables, and links them back to earlier layouts. Is there a plugin for Ruby in Eclipse that allows me to do this? Or is there another useful tool that can help me here? I haven't used Ruby myself, but it may be worth-while to check NetBeans. There is quite a lot of support for Ruby finding its way into NB. Check this page from the wiki. http://wiki.netbeans.org/RubyDebugging -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Code Quality Metrics
Jeremias Maerki wrote: I'm using FindBugs (as Eclipse plug-in) for some time now and it is really good. Not that I can really say yes to 100% of the suggestions. But about 98%. I'm not sure about the benefit of those reports. We've had the Checkstyle report for years now, but I doubt many people look at that often. Having those tools as IDE plug-ins is much more useful. But that needs to be set up by every dev him/herself. As Karen has been inactive for some time now, I can only assume that one of the developers wants a sex change. Who is it? -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Switching to Java 1.5
Jess Holle wrote: Max Berger wrote: Jess Holle schrieb: As of October of this year anything prior to Java 5 will be officially unsupported by Sun except where you have a paid support contract with them (including that for Solaris). Add to that the fact that Java 1.4 is so limiting for so many things and Java 5 is supported on even the most odd ball platforms (except Java ME, but I don't see FOP on ME...) I have to disagreee. AAMOF, java 1.5 is ONLY supported on a select number of plattforms, mainly the ones Sun provides the JDK for (or is licensed). Those are: Solaris / Sparc Linux / Intel Windows / Intel. OS X / PowerPC + Intel (licensed) *BSD / Intel (through emulation layers) There are some be specific IBM jdks (on IBM plattforms), but I have no experience with these. That's it. Anyone using any other plattforms (such as Linux / Sparc, etc.) has to use either the blackdown JDK ( stuck at 1.4 ), or different JVMs, such as Jikes, Kaffee, etc., ALL OF THEM stuck at 1.4 as well or not fully compatible (such as gcj). I have Linux / Sparc as a work machine, and have been looking for a way to run 1.5 code for quite a while... OpenJDK being the most promising solution (although still not working). I guess I shouldn't have said even the most odd ball platforms but rather all but the most odd ball platforms. Java 5 runs on HPUX and AIX machines as well -- as well as on Solaris x86. When you've got Windows, Mac OS X, x86 Linux, Solaris, HPUX, and AIX covered, I'd say that's pretty good. The other platforms are, er, odd balls. The question is whether you hold everything else back for the odd balls that seem unlikely to progress beyond 1.4. A view from the outside. With both HPUX and AIX, I imagine that there is another variable - which version of the OS supports 1.5. AIX versions don't come for the price of a Vista licence, and the same probably holds for HPUX. In addition, there may be minimum hardware requirements for upgrades. Talk to Chris about this. He has always been prominent in defending the FOP interests of his employers, and seems to know a bit about these issues. Wile we're on the topic... Concerning the issue of retaining 1.4 compatibility by hamstringing the use of 1.5 constructs: a truly, deeply, madly ridiculous idea. Go to 1.5, or don't. Simple. Don't complicate things with this notion of using generics, but nothing else. If (real) 1.5 is feasible, what about 1.6. There was a huge jump in the language itself between 1.4 and 1.5, which is why it has taken so long to wean the world off 1.4. There is not such leap between 1.5 and 1.6. The survey should canvas 1.5 and 1.6. I'd be curious to see how many systems support the first and not the second. The decision for FOP should be based, not on the end-of-life for a particular version, but on the pragmatic reality of 1.5 vs 1.6 support. That's the second glass of wine for the evening. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: try without catch in BlockStackingLM.getNextKnuthElements
Andreas Delmelle wrote:
On May 29, 2008, at 18:23, Vincent Hennebert wrote:
Could anybody explain me what is the purpose of the following piece of
code:
if (!breakBeforeServed) {
try {
if (addKnuthElementsForBreakBefore(returnList, context)) {
return returnList;
}
} finally {
breakBeforeServed = true;
}
}
that we can find, for instance, in BlockStackingLM.getNextKnuthElements?
Can't explain, other than that it seems to be a remnant of some
refactoring cycle without subsequential cleanup...
Isn’t it equivalent to the following:
if (!breakBeforeServed) {
breakBeforeServed = true;
if (addKnuthElementsForBreakBefore(returnList, context)) {
return returnList;
}
}
Indeed, this has the exact same outcome AFAICT.
Cheers
Andreas
What's the scope of breakBeforeServed?
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo
Jeremias, For what it's worth, I think you have done an extraordinary job with FOP. From my outside perspective, you have been the primary driver of the progress of the product since you came to the forefront of development. There's an inherent problem of clashing egos in OS development. I know all about that one. When that starts to happen, project productivity can dive until the conflict is sorted out. If you are feeling burnt-out, it might be time to consider tailing off your involvement in the project. Let me say, however, that on at least two occasions that I remember, Vincent has displayed a breath-taking and unwarranted arrogance. Vincent has a very high opinion of his own ability and I suspect he sees himself as the natural leader of the project. Unless Vincent develops some hitherto unsuspected humility and consideration, this difficulty can only end in one of you bowing out. That would be a pity. Jeremias Maerki wrote: On 18.04.2008 19:24:05 Vincent Hennebert wrote: Jeremias Maerki wrote: On 18.04.2008 16:51:37 Vincent Hennebert wrote: Jeremias Maerki wrote: On 18.04.2008 12:48:53 Vincent Hennebert wrote: Hi, A few comments: - some time ago I created a BreakUtil class in the o.a.f.util package. I think this class and KeepUtil should be put in the same place. Perhaps we could even merge them into a unique KeepsAndBreaksUtil class. I don’t really know what the best place would be. I put it in o.a.f.util because it already contains all sorts of utility classes, but o.a.f.layoutmgr would also make sense. WDYT? Whatever. I let you choose, but please take care of this. Whatever means: I don't care and you can fix this if it is important to you. Yeah, sure, let’s all do our own mess in our own corner and everything will be fine. I’m not asking you to finish my work, so please don’t ask me to finish yours. You created a class that’s closely related to another existing one that’s somewhere else; it’s your responsibility to try and maintain some coherence in the codebase by fixing this. Give me any good reason for not doing this simple thing, other than that you don’t care or you don’t have enough time, and I’m shutting up straight away. But you can’t call for contributors on one side and not do even the most basic cleaning behind you on the other side. Ok, let's do it this way: If one other FOP committers says that this (Vincent's idea) is something I should do, I'll do it. No discussion. Otherwise, it's 1:1 and I won't waste my time on something I don't think helps in any way. Remember, this is a democracy and a meritocracy here. http://www.apache.org/foundation/how-it-works.html#meritocracy http://www.apache.org/foundation/how-it-works.html#committers We've had a long discussion together around this last week during ApacheCon. IMO, you're going too far now. I increasingly feel like I'm your bitch. Today alone I lost almost half a day because I was too angry to work. I couldn't concentrate on what I should have been looking into. It's ok if you point out bugs and if I fix them because the bug is one of mine. I'm actually grateful for that. It's something else entirely if you have some idea and expect me to do the work. For free, notabene. I can also send you an invoice. In that case, I don't mind the additional work. OTOH, if I'm creating a mess here, maybe I should leave the project in order not to damage it any more because I care about it. Or better revert all my changes on Trunk in the last 3 years to undo the damage. Sorry for getting sarcastic, but it's not that far off. The other option: we could to switch to R-T-C: http://www.apache.org/foundation/glossary.html#ReviewThenCommit The PMC can decide to do that. That way we're always sure the community stands behind every change. But of course, you know what that would mean for the project. FOP community, if you think I drifted out of line lately, please set me straight. Vincent's voice is only one. I know this scene here is ugly and nobody wants to waste his precious free time on participating in fights between two people. The fight also doesn't help the project at all. Quite the opposite. In the case of Avalon.. Anyway, I keep finding myself in confrontations with team members from time to time. At this time, I'm seriously questioning myself and I'm not sure if that's just me and my thick head, if I care too much about the project, or if I simply have more attack area because I'm one of the most active people here. Some hints would be great (on- or off-list). Please be frank. Thanks and my apologies for the ugly scene! Jeremias Maerki (whose boss is Jeremias and to a certain degree the XML Graphics PMC, but certainly not Vincent as an individual) -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: DO NOT REPLY [Bug 42616] - fop bash script still broken under cygwin when current dir has spaces
Mark C. Allman wrote:
On Tue, 2007-10-30 at 13:32 -0700, [EMAIL PROTECTED] wrote:
Try
OLD_IFS=$IFS
IFS=
find ${FOP}/lib -name -name '*.jar'|while read jarfile
do
if [ -z $LOCALCLASSPATH ] ; then
LOCALCLASSPATH=$jarfile
else
LOCALCLASSPATH=$jarfile${pathSepChar}$LOCALCLASSPATH
fi
done
IFS=$OLD_IFS
find ${FOP}/lib -name '*.jar'|while read jarfile
do
if [ -z $LOCALCLASSPATH ] ; then
LOCALCLASSPATH=$jarfile
else
LOCALCLASSPATH=$jarfile${pathSepChar}$LOCALCLASSPATH
fi
done
would be almost perfect, and avoid the need for the change of IFS,
except that
the call to find places the whole while loop in a subshell, and
updates of
LOCALCLASSPATH are lost when it returns.
Change to:
for jarfile in `find ${FOP}/lib -name '*.jar'`; do
if [ -z $LOCALCLASSPATH ] ; then
LOCALCLASSPATH=$jarfile
else
LOCALCLASSPATH=$jarfile${pathSepChar}$LOCALCLASSPATH
fi
done
-- Mark C, Allman, PMP
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com, 617-947-4263
BusinessMsg -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution
I think this brings back the original problem.
Peter
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
Vincent Hennebert wrote: Hi, Manuel Mall a écrit : On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote: snip/ Interestingly Java 1.5 has added the Integer.valueOf(int) method with the following comment: Flyweight pattern. That's what I was looking for before replying to Andreas' commit, and I was surprised to not find it in the 1.4 standard library. A good thing it finally got added. Not a pattern. It's an object cache. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: IntMap.java
J.Pietschmann wrote: Vincent Hennebert wrote: Shall we launch a poll on fop-user about abandoning support for 1.4 and require 1.5 as a minimum? :-] A poll: maybe. Abandoning 1.3: Not yet. If the usage of those hash maps is only in a few places, we could provide JDK dependent code and tell people that FOP runs faster on JDK 1.5. J.Pietschmann FOP should run markedly faster on 1.6 without any changes. Just about everything else does. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Anyone heard from Andreas?
I haven't seen anything from Andreas for some time now, and I was wondering if anyone had heard from him privately. -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: Generated source files? (Re: Small problem with Netbeans on fop-users@)
Andreas L Delmelle wrote: On Mar 10, 2007, at 15:34, Vincent Hennebert wrote: Thomas Zastrow a écrit : snip / But I haven't a directory called gensrc? I downloaded the SVN-version just minutes ago. This directory contains source files automatically generated during the build process. To create it you have to run ant codegen in the root directory of FOP. FWIW, the XML sources of these generated files hardly ever change, so I think we may even consider replacing these with pregenerated java classes...? It always seems to confuse people who are interested in contributing code. Then, once you start wondering why these need to be generated and cannot simply be added as java sources, you'll quickly realize there is no good reason for that. Replacing maintenance of 15 classes with maintaining 2 stylesheets and 15 XML source files hardly seems worth the trouble... :/ Cheers, Andreas Novel idea. http://marc.theaimsgroup.com/?l=fop-devm=105728457029132w=2
ANN: HyFo hyphenation module V 1.0.0 released
The Folio project announces the initial release of its stand-alone hyphenation module, HyFo. HyFo is released in binary form as jar files and in source form as zip files. See http://sourceforge.net/project/showfiles.php?group_id=119136 HyFo features include: * Hyphenation patterns embedding re-spelling hyphenation, such as are required in Dutch, Hungarian, Swedish, Catalan and pre-reform German orthography. These are the hyphenations expressed by the TeX discretionary hyphenation facility. This feature is currently active only in the Hungarian patterns, and in a special versions of the GB and US files with the variant _18, that is, the hyphenation trees en_US_18 and en_GB_18. * Easy quarantining of unacceptable licences from your application. Because the hyphenation trees, built from individual language pattern files, are themselves stand-alone, users can pick and choose the pattern jars they wish to install, insulating applications from the effects of particular licences. * No rebuilding required to add new pre-built hyphenation pattern trees. Adding a new pre-compiled hyphenation instance is as simple as dropping a new language jar onto the classpath. * Integration with Java 2D text processing is provided. Hyphenation attributes can be processed along with other text attributes by AttributedCharacterIterators. * HyFo hyphenation is fast; more than 50% faster than the Fop hyphenator. HyFo trades off memory usage and one-off start-up time against the speed of hyphenating individual instances. * The HyFo API includes methods to present hyphenation results in a FOP-compatible manner. * HyFo supports alphabets containing supplementary Unicode characters. There are no known requirements for Liang-style pattern hyphenation of such alphabets. See the HyFo web pages at http://defoe.sourceforge.net/hyfo/hyfo.html -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/
Re: FOP Memory issues (fwd from fop-users)
On Tue, 2007-01-09 at 16:52 +0100, Vincent Hennebert wrote: Richard a écrit : snip/ I'm also currently reading through Knuth's Digital Typography. Can anyone point out any sections I should pay particular attention to w.r.t. FOP's usage, (Digital Typography caught my eyes. I'll try to respond to the rest later.) Chapter 3, Breaking Paragraphs Into Lines, is definitely THE chapter to read. The first 2 chapters are dealing with font rendering, which goes too far for us --but it may be interesting for your personal culture. I haven't read the rest but it seems very TeX-oriented to me. Maybe interesting, but obsoleted by the current font technology (Type1, OpenType) anyway. I've considered to describe the linebreaking algorithm in a less cryptic manner (variable names of more than one letter, mainly) on the Wiki [1], but have never had the time to do it. If you ever want to do that, that would be very valuable I think! [1] http://wiki.apache.org/xmlgraphics-fop/KnuthsModel Vincent And I thought about describing Knuth and Plass' algorithm in a less cryptic manner, and from a slightly different point of view. http://defoe.sourceforge.net/folio/knuth-plass.html N.I.H. Peter
Re: XSL-FO 2.0 workshop in Heidelberg next week
On Tue, 2006-10-10 at 12:42 +0200, Simon Pepping wrote: On Mon, Oct 09, 2006 at 11:45:08PM +0200, J.Pietschmann wrote: Jeremias Maerki wrote: If anyone has any requirements for XSL-FO 2.0 which I should bring up at the workshop in Heidelberg next week, please let me know. More radical thoughts: - Deprecate mixing inlines and blocks :-P Block content in inline content is the natural organization of displayed formulas and tables. Demanding that FO generating stylesheets separate them is moving the burden back to them. I am not in favour of that. Regards, Simon It would, however, be useful if the editors could get their story straight on this. I've never been able to work out exactly what was the expected behaviour of blocks within inlines. Peter
Re: keep...=always and Knuth penalties
On Wed, 2006-06-21 at 16:50 +0200, Jeremias Maerki wrote: Have you tried the Disposition of Comments? I don't know how accessible they are to Google. They are accessible through the list archive at W3C. I've looked at those I found but I found no listing of all XSL-related ones. Jeremias, I'm not sure that they are accessible. The only way I've ever been able to find them is by following links from messages in the xsl-editors list. It's not a big deal for me; I'll go with always=always. If you need it resolved, you might be best to write to the editors. Paul Grosso will probably respond quickly. Peter
Re: keep...=always and Knuth penalties
On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote: Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. I'll see if it's on the laptop at home. All I remember about it was that it was a reply from one of the editors. Where were you looking? Peter
Re: keep...=always and Knuth penalties
On Wed, 2006-06-21 at 16:24 +0200, Jeremias Maerki wrote: On 21.06.2006 16:19:30 Peter B. West wrote: On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote: Thanks, Peter. I went looking for that reference but wasn't lucky. I gave up after almost 30 minutes. Could you dig up that reference for us? The only post I found was one by G. Ken Holman which was never answered: http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0028 On 21.06.2006 11:04:53 Peter B. West wrote: On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote: Jeremias Maerki wrote: On 19.06.2006 15:45:36 Luca Furini wrote: It seems to me that the prescribed behaviour requires a keep constraint with force = always to be satisfied *always* :-), even if this would mean having some overflowing content. Obviously, we disagree here. I read it so that always can also be relaxed if the keep cannot be satisfied. Did anyone check what other implementations do? A quick test shows that AntennaHouse's xslformatter satisfies all the keeps, even when this means having some content overflow the body region (the overflowing content is actually clipped), while RenderX's xep relaxes a keep constraint in order to avoid overflows. From memory, this issue was clarified in a posting to the editors list some time ago (2 years or more, I think.) always means always, which makes sense. I'll see if it's on the laptop at home. All I remember about it was that it was a reply from one of the editors. Thanks a lot! Where were you looking? Using friend Google, my mail client and http://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=index-grp=Public__FULLindex-type=ttype-index=xsl-editors Have you tried the Disposition of Comments? I don't know how accessible they are to Google. Peter
Re: PDFFontDescriptor and PDFFactory
On Fri, 2006-05-26 at 12:54 +0100, Chris Bowditch wrote:
Peter B. West wrote:
A colleague of mine has just found this:
From PDFFontDescriptor
*/
public PDFFontDescriptor(String basefont, int ascent,
int descent, int capHeight, int flags,
PDFRectangle fontBBox, int italicAngle,
int stemV) {
From PDFFactory
descriptor = new PDFFontDescriptor(desc.getFontName(),
desc.getAscender(),
desc.getDescender(),
desc.getCapHeight(),
desc.getFlags(),
new
PDFRectangle(desc.getFontBBox()),
desc.getStemV(),
desc.getItalicAngle());
Your message is a little cryptic Peter. Are you trying to say there is a
bug caused by the fact PDFFactory mis-uses the Constructor to
PDFFontDescriptor? (looks like StemV and italicAngle arguments are
transposed)
Chris
Chris,
That's what he pointed out.
Peter
PDFFontDescriptor and PDFFactory
A colleague of mine has just found this:
From PDFFontDescriptor
*/
public PDFFontDescriptor(String basefont, int ascent,
int descent, int capHeight, int flags,
PDFRectangle fontBBox, int italicAngle,
int stemV) {
From PDFFactory
descriptor = new PDFFontDescriptor(desc.getFontName(),
desc.getAscender(),
desc.getDescender(),
desc.getCapHeight(),
desc.getFlags(),
new
PDFRectangle(desc.getFontBBox()),
desc.getStemV(),
desc.getItalicAngle());
Peter
Re: Question about status of Bidi support, and Arabic/Persian shaping!
On Fri, 2006-05-05 at 08:43 +0200, Jeremias Maerki wrote: This is good news. I did not study the problems around non-LTR texts so I can't say anything useful about this. I think it is preferrable to reuse code from the Java class library if it covers our requirements (among them: maintain JDK 1.3 compatibility). Sadly that means that java.text.Bidi is a little problematic, except if we say that Bidi support is only available under JDK 1.4 but that might complicate the implementation additionally. If we can reuse code from our sister project Batik, that's probably better. Introducing an external library will take careful consideration. We have to make sure, among other things, that the licensing situation is ok. I don't know of anyone currently working on a Bidi impementation. If someone does, I expect that person to speak up. I am. Using Java 1.5 for the basics, and Java 1.6 for kerning and ligatures. I suppose you were aware of that though. Peter
Re: Question about status of Bidi support, and Arabic/Persian shaping!
On Fri, 2006-05-05 at 10:59 +0200, Jeremias Maerki wrote: On 05.05.2006 10:51:35 Peter B. West wrote: On Fri, 2006-05-05 at 08:43 +0200, Jeremias Maerki wrote: This is good news. I did not study the problems around non-LTR texts so I can't say anything useful about this. I think it is preferrable to reuse code from the Java class library if it covers our requirements (among them: maintain JDK 1.3 compatibility). Sadly that means that java.text.Bidi is a little problematic, except if we say that Bidi support is only available under JDK 1.4 but that might complicate the implementation additionally. If we can reuse code from our sister project Batik, that's probably better. Introducing an external library will take careful consideration. We have to make sure, among other things, that the licensing situation is ok. I don't know of anyone currently working on a Bidi impementation. If someone does, I expect that person to speak up. I am. Using Java 1.5 for the basics, and Java 1.6 for kerning and ligatures. I suppose you were aware of that though. Well, the requirement for 1.5 or even 1.6 pretty much rules out your implementation for us. Jeremias Maerki :) Peter
FOPDEV.org
Fop-devs, What have you been hiding? http://www.fopdev.org/ Peter smime.p7s Description: S/MIME Cryptographic Signature
Properties - was Sponsorship
Peter B. West wrote: Finn Bock wrote: [Peter B. West] The alt-design property code was, back then, in my eyes, code written by a person who did not intuitively create object oriented design. ... It was, IMO, not a good fundation for further work. Fair enough, apart from the deferred functionality, but irrelevant. We're talking here about ideas and implementation details. I have then later looked at different times, one where I made a incorrect description of how alt-design stored references from fo-object to properties, an other when I wanted to understand why you though alt-designs Property/PropertyValue was any different from head's PropertyMaker/Property. A discussion I am always willing to have, if only to learn more about your approach. I *do* like pretty code. I asked you about it, because I had plans to adopt it. But I was not persuaded that you had the thorny problems solved, so I held off. When it's completed, I'll look again. Finn, I've just had another look at the properties code. It's not a pretty sight, is it? Understandable, because the properties system does not lend itself to simple solutions. I'll pass on adopting it though. The properties code in Folio is already considerably more comprehensible, and will become even more so when the layout work converges. In any case, it was reassuring to see the completely accidental correspondences between your work and mine. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Thanks to Jeremias
Jeremias has sent a most magnanimous email to me. It reflects as well on him as my imputations as to his motives reflect badly on me. My apologies to Jeremias. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: script property
Manuel Mall wrote: On Wed, 5 Oct 2005 04:17 pm, Jeremias Maerki wrote: On 05.10.2005 09:46:18 Manuel Mall wrote: While I am at it (this whole alignment stuff I mean) we may as well do it properly. This would include support for the script property. The allowed values for script are defined for example here: http://www.unicode.org/iso15924/iso15924-codes.html. I assume we don't bother to validate if a correct code has been provided as we don't do that for the country and language properties either (should we? If we do we need more external config files or expand fop.xconf to hold those values as they tend to change over time). We don't have to but we could. Since this is not something that changes often I wouldn't put it into the config file, but in resource files instead. OK - makes sense. Validation issues considered in alt-design circa 2002. See CountryLanguageScript.java in the alt-design code for an attempt at this. Generated from xml-lang.xml and xml-lang.xsl. No baselines. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Sponsorship
On Fri, Sep 30, 2005 at 08:27:45AM +0100, Peter B. West wrote: Jeremias Maerki wrote: On 29.09.2005 11:58:57 Peter B. West wrote: I can understand that some sponsors may be sensitive to divulging such information, for at least two reasons. Firstly, the treat of being inundated with begging letters, and secondly, the possibility that they might be upsetting their own business partners. Before you took up the sponsorship offer, you mentioned to me that it was on the cards, which I appreciated. I assume you told others as well. Targeted sponsorship is potentially extremely disruptive to a group, and it seems to me that the process must be as open as possible. If it can't be as open as the code, it should be nearly so. Do you mean that such a sponsorship changes the relations within the group? It certainly does. I feel that Jeremias has done an admirable job in managing the relations within the group, and in balancing his full time input in FOP with the more limited input of other group members. Simon, I've been stewing on this for quite a while, and as you, at least, seem to have missed the point, I'll vent. Some background. I've been working on the implementation of this cow of a Recommendation since early in 2001, mainly on FOP. In that time, I have had not one red cent of financial support. I'm not the only one in that situation, just the one who has been doing it the longest. Others have had employer support to devote some (or all) of their time to FOP, and Jeremias has for some time been sponsored, whatever that means. (The fact that some get paid to work on open source is not unusual, particularly at Apache. Have a look through the committers on say, Xerces or Xalan, and look for the ibm.com addresses. I could also mention Sun and BEA.) The outside observer of the FOP code base and web site could be excused for thinking that I had never existed on this project. I wrote code for a year before I got committer status, incidentally at the same time as Jeremias and Joerg. The reason it took me so long was that I was not toeing the party line - FOP HEAD. My contributions could not be incrementally added to the existing line of development, so they didn't exist. The only way I got committer status eventually was through the intervention of Nicola Ken Barozzi, who was appalled that forked code was being hosted outside Apache. That code was alt-design properties code. It seems to me that many of the ideas and implementation details of alt-design are now sitting in the FOP code base. This is true whether Finn ever looked at the alt-design properties code. It ain't over yet.[1] Does any record of any of this remain on the web site? No. All trace of alt-design has been vigorously scrubbed from the site. A bit thank you to Glen and to Jeremias. Not only does this amount to the re-writing of FOP history, but it was detrimental to the development effort. A number of observations which have been made recently were discussed in detail in the alt-design documentation, notably in respect of space-resolution and footnotes. Rewriting history is a pernicious activity at the best of times. What infuriates me about this exercise is not only its immediately detrimental effects on me, but what I perceive to be its motivation. As to the first, I cannot, for example, point anyone who is interested to the relevant parts of the web site and say, That's what I was doing for the past few years. This is important anyway, but in my case it is more important. I started work on FOP at the beginning of the tech wreck. That hit my home town particularly hard. In addition, my skills were stale. XSL-FO has been my school of Java. The bottom line was that I had almost no work in IT over that period. I lived off savings, I lived off unemployment benefits, I sold liquor at a bottle shop, I was supported by my wife. My efforts on this project, and now Folio, were, and are, critical to my prospects of employment. Jeremias has known my situation for some time. Let me repeat that. When Jeremias went about the complete purging of all traces of my work from the site, he knew my professional situation. You might say that it doesn't matter because I can simply put such things on the Folio site. But of course, the Folio site is not, for some time, at least, going to get the traffic, nor does it have the same weight. Which brings me to the motivation. I don't doubt that Jeremias does not believe in my design ideas. That makes the behaviour even more bizarre. If the ideas are no good, let them stand naked to inspection. No-one will be interested. No, that's not enough. Someone *might* be interested, and Jeremias *might* lose a potential developer to Folio. That is, someone probably working for nothing, might not contribute to FOP. And that would not be in Jeremias' personal financial interest. That's
Re: Sponsorship
Finn Bock wrote: [Peter B. West] ... That code was alt-design properties code. It seems to me that many of the ideas and implementation details of alt-design are now sitting in the FOP code base. This is true whether Finn ever looked at the alt-design properties code. It ain't over yet.[1] I did, before I became a committer. Back then I evaluated the different branches (0.20, alt and head) and made a decision on which one to work on. The alt-design property code was, back then, in my eyes, code written by a person who did not intuitively create object oriented design. Guilty as charged. My apologies. I'm kind-of old fashioned. I was looking to understand the problem, and solve it, especially the hard parts. For instance, parsing font. That problem was addressed in 2002 in alt-design. When did that make it into FOP? I can't say it was solved, because there may well have been bugs in it at that stage. But the code was there, as it was for a number of other hair-raising properties. I don't know the current situation in detail, but for some long time, alt-design had overall better coverage of properties than the new code. More importantly, it had been thought through. There were gaps, but all of the nasty stuff was covered, and there were no surprises, except for the issue of percentages, which is what sent me in another direction. There were no kludges, waiting for me to confess down the track. Like I said, I'm old-fashioned. When I say something is done, I mean that it is done. If there are areas that need fixing, I'll say so, up front. It was, IMO, not a good fundation for further work. Fair enough, apart from the deferred functionality, but irrelevant. We're talking here about ideas and implementation details. I have then later looked at different times, one where I made a incorrect description of how alt-design stored references from fo-object to properties, an other when I wanted to understand why you though alt-designs Property/PropertyValue was any different from head's PropertyMaker/Property. A discussion I am always willing to have, if only to learn more about your approach. I *do* like pretty code. I asked you about it, because I had plans to adopt it. But I was not persuaded that you had the thorny problems solved, so I held off. When it's completed, I'll look again. Does any record of any of this remain on the web site? No. Plagerism? Not an accusation I'm making, Finn. Not a single line from alt-design has ever been committed to head by me! Not an accusation I'm making. ...whether Finn ever looked... But thanks for the response. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Maintainability
Manuel Mall wrote: On Thu, 29 Sep 2005 11:50 pm, Peter B. West wrote: Fopsters, I've always been somewhat sceptical of the new approach to page breaking, although I was prepared to concede that it would be a great achievement if you pulled it off. However, the closer the development has come to fruition, the more some of my original concerns have been reinforced. Think about the enormous amount of intellectual effort that has gone into mapping the problem into Knuthian. That effort is still under way. How is this going to be maintained? Where are the Knuthian speakers who are going to do that job over the next few years? I'm surprised, in fact, that some of the old hands have not raised this question already. Peter, I don't get it what you are aiming at here. Are you saying that the Knuth approach to line or page breaking is inherently more difficult to understand and therefore harder to maintain? Apart from being one of the best (in terms of visual quality of the output) algorithms for breaking it is also IMO inherently simple. This is one of the beauties of many of Knuth's works. He is IMO a brilliant Computer Scientist who manages to solve complex problems using simple concepts and algorithms. The concepts and algorithms are also well documented in papers and books which are usually accessible through your nearest university library. Just take the Breaking Paragraphs into Lines paper. Yes, it is over 80 odd pages long but the important concepts are explained in the first 10 pages. In my case, when I delved cold into the fop layout code I had no idea what was going on, but after reading the initial part of the paper it all suddenly made sense. So, where is the problem - Fop is using well documented concepts and algorithms to do its line and page breaking. Why should it be harder to maintain than some home cooked solution not backed up by previous research / papers / implementations (Tex)? And if you take the recent discussions mainly driven by Jeremias regarding the bpd space resolution the core of the problem is not mapping it into the appropriate Knuth sequences. It is the implementation of the space resolution rules themselves, i.e. figuring out how much space to leave or not leave in a particular situation, which is the hard part. Generating the appropriate Knuth sequence once you know what the resolved space is is easy. And quite a few of the stuff is also documented on the WIKI. In summary, and I can speak here from my own recent experience, I don't share your concerns about the Knuth approach increasing the maintainability cost of the fop code base. If you guys are happy with how the design is shaping up in terms of maintainability, great. There had been no discussion about this aspect, now there is. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Sponsorship
Jeremias Maerki wrote: On 29.09.2005 11:58:57 Peter B. West wrote: Jeremias, I meant to ask you when you mentioned your sponsor; who is it? I'm not at liberty to disclose that at this point. I'm sure they're happy with the work you've put in. Yes, they are. We've already achieved one of the major goals: To bring FOP out of its stagnation and make it more interesting for people to jump in and help again. FOP's gona live! :-) Jeremias Maerki I can understand that some sponsors may be sensitive to divulging such information, for at least two reasons. Firstly, the treat of being inundated with begging letters, and secondly, the possibility that they might be upsetting their own business partners. Before you took up the sponsorship offer, you mentioned to me that it was on the cards, which I appreciated. I assume you told others as well. Targeted sponsorship is potentially extremely disruptive to a group, and it seems to me that the process must be as open as possible. If it can't be as open as the code, it should be nearly so. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Maintainability
Thanks to Luca for his (perhaps entirely co-incidental) posting to the Wiki. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Maintainability
Luca Furini wrote: Peter B. West wrote: Thanks to Luca for his (perhaps entirely co-incidental) posting to the Wiki. Well, not entirely co-incidental! :-) I started writing the page some time ago, but never found the time to finish it: your message made me think I really couldn't put this off any longer, so I added a few things and posted what was ready. I'd try and add the missing parts as soon as possible. Comments, questions, suggestions, and especially additions :-) are most welcome! Regards Luca Luca, There seem to be some misapprehensions about what you are attempting; perhaps they are mine, so please clarify this. As I understand it, the mature, well-documented technology is the line-breaking, as in Breaking Lines Into Paragraphs. Using this model for page-breaking is something that has been speculated about, in particular by Plass. However, in implementing this, you and the others are breaking new ground. If this is the case, then it is quite inaccurate to describe the page-breaking as mature, well-understood, well-documented and well-behaved technology. Is that fair? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Static methods
Finn, I noticed that you extracted numeric function methods as statics into a class of their own. Was this for aesthetic or performance reasons? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Static methods
Finn Bock wrote: [Peter] I noticed that you extracted numeric function methods as statics into a class of their own. Was this for aesthetic or performance reasons? The methods in NumericOp? They are called from multiple places which does not have anything in common. So I put the methods in NumericOp to avoid duplication of the few lines in each method. There was no performance reasons behind that decision. regards, finn Thanks Finn. I thought it might have been something you had learned about JVMs while working on Jython. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Maintainability
Fopsters, I've always been somewhat sceptical of the new approach to page breaking, although I was prepared to concede that it would be a great achievement if you pulled it off. However, the closer the development has come to fruition, the more some of my original concerns have been reinforced. Think about the enormous amount of intellectual effort that has gone into mapping the problem into Knuthian. That effort is still under way. How is this going to be maintained? Where are the Knuthian speakers who are going to do that job over the next few years? I'm surprised, in fact, that some of the old hands have not raised this question already. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: alignment-adjust property
Manuel Mall wrote: This is another of those spec interpretation questions. Sorry to populate this list with so many of these questions but this is a source of real irritation for me in the moment. I just want to get sub/superscripts working and do it properly and I am hitting all these murky (as Peter put it) things in the spec. Don't apologise for actually reading the Recommendation, and thinking about it. The fact is that there is not enough of that done by those who are implementing the Recommendation, as evidenced by the existence of these bugs in the document. No matter what the interpretation, 7.13.1 and 7.13.2 have editorial bugs which need to be clarified. Think about it. How many commercial implementations are out there? The same bugs are still present in the 1.1 draft. (See Section 7.14). You found it, so you get to write to the editors. If you are apprehensive about that, talk to me further off-list, or to Glen (who has communicated quite a lot with the editors, and who has popped up again) or Victor. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: inline stacking and baseline scaling
Manuel Mall wrote: My apologies for this relatively long post. I am still struggling to come to grips with some of the fundamentals of line building. And without having a clear picture of that it is impossible to come up with a decent design. Interestingly (?) all my conceptual problems occur when one starts to nest inlines (for example simple math formulas) and shift baselines around. Any way the spec in 4.6.1 defines what a 'properly stacked' inline-area is. Items 1. and 2. deal with stacking in IPD but item 3 repeated here deals with the BPD: 3. For any inline-area descendant I of P, the distance in the shift- direction from the dominant baseline of P to the alignment-point of I equals the offset between the dominant baseline of P and the baseline of P corresponding to the alignment-baseline trait of I, plus the sum of the baseline-shifts for I and all of its ancestors which are descendants of P. The first summand is computed to compensate for mixed writing systems with different baseline types, and the other summands involve deliberate baseline shifts for things like superscripts and subscripts. In 7.13 there are examples given and they all work with the above definition. Now lets take this example: fo:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop /fo:inline /fo:block The inline gets a new baseline table scaled to its font-size because of the dominant-baseline=reset-size setting. Note that the dominant-baseline-indentifier has not changed. Its still alphabetic although that baseline does not align any more between the two areas because of the rescaling of the baseline table. Now lets give the text top a small suffix. fo:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop fo:inline font-size=.5em alignment-baseline=central tiny/fo:inline /fo:inline /fo:block So tiny becomes some small text aligned on the central baseline as established after rescaling. The problem is that the positioning of tiny violates the rule 3. above on proper stacking with respect to the line-area created by the fo:block. It is OK with respect to its direct ancestor but it fails when applied recursively. This is because rule 3. doesn't cater at all for rescaling of the baseline table, it only deals with changing the alignment point (In my example its first moved to text-befored-edge and then to central) and baseline-shifts. But I couldn't find anywhere in the spec a notion that baseline rescaling involves a baseline shift. The problem of course is that when a baseline table is rescaled there is no uniform shift and the shift amount per baseline also depends on the alignment. May be rule 3 is not meant to be applied recursively but than it its formulated inconsistently with the rest of the spec. I can't say for sure, but I think there may be some confusion about the relationship between the alignment-baseline of nested inline-areas and the dominant-baseline of the containing line-area. The nominal-requested-line-rectangle is implicitly defined with respect to the dominant-baseline, text-depth and text-altitude on the parent of the line-area. The situation with inheritance of properties involved with these calculation is also confused. They do no inherit, except that, for dominant-baseline, components of the scaled-baseline-table propagate for formatting object children with the default initial value of auto for dominant-baseline. Apart from that, neither alignment-baseline nor dominant-baseline inherit, so they must revert to relativity to, I think, the values holding for the line-area, whenever a new inline formatting object, including nested objects, is encountered. In the example you have used, the alignment-baseline of central on tiny simply moves the central line of tiny into correspondence with the central line of Some text. The scaled-font-table remains the same as for top; only the size of the glyphs changes. See the third example: fo:inlineApguru fo:inline font-size='.75em' Exji /fo:inline /fo:inline So rule 3 holds. There have been no baseline-shifts (rescaling the font-table doesn't count as a baseline-shift.) Maybe. Still seriously confused Surely not. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: inline stacking and baseline scaling
Manuel Mall wrote: On Mon, 26 Sep 2005 06:19 pm, Peter B. West wrote: Manuel Mall wrote: snip/ Peter, thanks for your feedback. I have deleted most of my original post to keep this to a reasonable size. Further comments inline. Just repeating my example here: fo:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop fo:inline font-size=.5em alignment-baseline=central tiny/fo:inline /fo:inline /fo:block I can't say for sure, but I think there may be some confusion about the relationship between the alignment-baseline of nested inline-areas and the dominant-baseline of the containing line-area. The nominal-requested-line-rectangle is implicitly defined with respect to the dominant-baseline, text-depth and text-altitude on the parent of the line-area. Yes, agreed. The situation with inheritance of properties involved with these calculation is also confused. They do no inherit, except that, for dominant-baseline, components of the scaled-baseline-table propagate for formatting object children with the default initial value of auto for dominant-baseline. Apart from that, neither alignment-baseline nor dominant-baseline inherit, so they must revert to relativity to, I think, the values holding for the line-area, whenever a new inline formatting object, including nested objects, is encountered. I agree that neither of these properties inherit but they all have default values. However, the baseline table does propagate as you said and may or may not be rescaled depending on the alignment properties explicitly set. If none are set the baseline table stays unchanged. In the example you have used, the alignment-baseline of central on tiny simply moves the central line of tiny into correspondence with the central line of Some text. This is were my interpretation differs from yours. IMO for the innermost inline (tiny) the baseline table that applies is the one established by the rescaling of the table by its parent inline (top). Therefore tiny should be aligned to the central baseline of the rescaled table. For the inline tiny the following alignment property values apply: alignment-adjust=auto = computed value is central alignment-baseline=central = computed value is central baseline-shift=baseline = computed value is 0 dominant-baseline=auto The most interesting bit is the auto setting for the dominant-baseline as it says in the spec for that case: if this property is not on a block-level formatting object, then the baseline-identifier for the dominant baseline, the derived baseline-table, and baseline-table font-size remain the same as those of the parent formatting object. As the parent formatting object is the inline top I interpret this as: tiny's baseline table is the same as top's (which is the rescaled baseline table from the fo:block). tiny's baseline table is not being rescaled to tiny's font-size. The dominant-baseline-identifier still stays alphabetic. FWIW (not that much I agree) both AntennaHouse and RenderX behave as I outlined. The scaled-font-table remains the same as for top; only the size of the glyphs changes. Not sure I understand what a scaled-font-table is but as said above IMO the scaled-baseline-table on tiny is the same as on top. See the third example: fo:inlineApguru fo:inline font-size='.75em' Exji /fo:inline /fo:inline Yes, not disputed. So rule 3 holds. There have been no baseline-shifts (rescaling the font-table doesn't count as a baseline-shift.) Yes, in your interpretation, not in mine. I'm looking for an interpretation that is consistent with Rule 3. This is a murky area of the Rec, and one I have never understood. Why not send your original query to the editors, so that they can consider whether anything needs to be clarified before 1.1? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: More style issues
Jeremias Maerki wrote: +1 to all three points. But I'll never define a variable called blockProgressionDimension! That's always going to be bpd for me, but then ipd and bpd are so omnipresent so it shouldn't be a problem. blockProgressionDimension or blockProgressionDirection? Exceptions prove the rule, don't they? :-) They certainly throw it into contrast. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Manuel Mall wrote: PS: I can imagine Victor smiling now :-) : I told you so that not leaving all property resolution to the LM stage is going to cause trouble. Not just Victor, Manuel. But please press on re-discovering the wheel. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Chris Bowditch wrote: Manuel Mall wrote: Fair enough, btw its not painful for me at all. I have joined the project with the goal to help to get FOP 1.0 out of the door in a relatively short timeframe (meaning months not years). To achieve that I am more than prepared to be pragmatic in the sense of getting things working satisfactorily than getting things perfect and at their most elegant. That doesn't mean I want to hack and slash. Good design is very important me. But there is still this goal to aim for as well and compromise may be in order at times. This is an excellent goal. Sometimes it is all too easy to aim for 100% perfection and then FOP gets stuck - just like it has been for 2 years prior to 2005. Compromise is the key to getting 1.0 out of the door. Couldn't let that one go by, Chris. These issues, which were critical to the creation of both Folio and FOray, were being thrashed out around the beginning of 2003. You've been around long enough to know that, haven't you? So for more than two years, the pragmatic Fop developers stuck their heads in the sand. The project stalled. Point the finger at those who refused to see what is now coming to the surface, and what will still have to be solved. How pragmatic. And isn't there still FOP 2.0 down the track for another round of serious redesign and refactoring if so desired? Hope this makes sense - especially to the active committers. Perfect sense. Keep up the great contributions! Perfect, in some imperfect sense of the word. Chris Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Chris Bowditch wrote: Peter B. West wrote: snip/ Couldn't let that one go by, Chris. These issues, which were critical to the creation of both Folio and FOray, were being thrashed out around the beginning of 2003. You've been around long enough to know that, haven't you? So for more than two years, the pragmatic Fop developers stuck their heads in the sand. The project stalled. Point the finger at those who refused to see what is now coming to the surface, and what will still have to be solved. How pragmatic. Yes I was around back in 2003. My apologies for offending anyone I wasn't clear enough with my offhand remarks. And yes I have buried my head in the sand as you put it. Not because I wanted to, but because my employers expect me to spend time elsewhere. I'm not going to add any more to this discussion, as I don't want to cause any further offense. Chris No offence taken. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: StAX, JAXP 1.4
Elliotte Harold wrote: Peter B. West wrote: But of course, I'm talking about Folio, which was built on a pull-parsing model before I had ever heard of pull-parsing, because it was the screamingly obvious thing to do. It gives me acute pleasure to see my original design decisions vindicated by the the development of the StAX API, and the current surge of interest. So, all of this, and more, _is_ the case. My invitation stands. I haven't looked at Folio yet. Perhaps it's screamingly obvious that it needs a pull model. If so it's the first such application I've encountered. The really useful pull models are implemented on top of tree structures, and provide random access. I've yet to see a case where a one-way streaming pull parser did anything that couldn't be accomplished equally easily and efficiently with a push parser. The primary benefit to pull parsers is that some developers either don't understand or simply don't like the observer design pattern as embodied in push parsers, and prefer the iterator design pattern as embodied in pull parsers. Whatever floats your boat. However there's no evidence that either pattern is in any way fundamentally superior to the other, except as a matter of developer taste. As a practical matter, existing SAX parsers are much better optimized and debugged than existing StAX parsers. They're simply a more mature product. Elliotte, We're seriously OT here, so I'll off-line my response. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: StAX, JAXP 1.4
Elliotte Harold wrote: Peter B. West wrote: Fopsters, Some of you may be aware of the activity going on around StAX. Java 1.6 (Mustang) was to have included JAXP 1.4, but that looks to be on hold until Dolphin. However, StAX will be part of it, and soon enough, SAX will be a dim memory. Yeah, right. I give this claim about as much credence as I gave the claims that schemas were going to replace DTDs. StAX isn't as disastrously bad as schemas were, but it certainly hasn't justified the hype either. So far I've seen approximately no evidence that it provides any noticeable improvements over SAX. Some people find StAX easier to use the SAX for some use cases, but not all. I suspect Sun never saw the performance improvements they were hoping for from StAX which is why they're now off and running up another wrong path called Fast Infoset. (I was just looking at some 3rd party performance numbers on that this morning, and guess what? It isn't working out either.) I don't think SAX is the ultimate in XML performance, but I suspect even a factor of two improvement over SAX is going to require something a lot more radical than StAX. Elliotte, So I exaggerated. But how many better applications can you find me for StAX than processing XSL-FO? If StAX has no application here, it has no application. Is that what you're saying? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: StAX, JAXP 1.4
Elliotte Harold wrote: Peter B. West wrote: So I exaggerated. But how many better applications can you find me for StAX than processing XSL-FO? If StAX has no application here, it has no application. Is that what you're saying? You're asking the question backwards. We should not be asking, Is XSL-FO the best possible use case for StAX? We should be asking, Is StAX the best possible API for XSL-FO? One certainly good do write FOP on top StAX, but you can also do it with SAX; and since it's already working with SAX I see no particular reason to throw away the working SAX code and replace it with StAX. If we were starting from scratch, and if the developers were more familiar with StAX than SAX, and if StAX parsers were as mature, proven, and ubiquitous as SAX parsers, then writing FOP on top of StAX might be reasonable. However none of that's the case. But of course, I'm talking about Folio, which was built on a pull-parsing model before I had ever heard of pull-parsing, because it was the screamingly obvious thing to do. It gives me acute pleasure to see my original design decisions vindicated by the the development of the StAX API, and the current surge of interest. So, all of this, and more, _is_ the case. My invitation stands. Don't let your feet get wet, Elliotte. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Plain old line-breaking
Luca Furini wrote: Peter B. West wrote: Is there any design documentation about plain old line Knuth breaking, as implemented by Luca? I see lots of stuff in the Wiki about page breaking, but can't see the original. As Jeremias told, there isn't much official documentation about the basics of the new breaking algorithm. A wiki page, or maybe more than one, could be very useful, even to keep track of the points that could need some more work. I have thought of writing it some times ... but unfortunately I never found the time to do it! :-( Thanks Luca. Peter --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
Re: Eclipse with JDK 1.5
Jeremias Maerki wrote: I don't do native JDK 1.5 development (i.e. no generics etc.) but regularly compile and test with 1.5 and so far absolutely no problems. On 17.08.2005 19:31:14 Peter B. West wrote: How's Eclipse with 1.5 nowadays? Thanks. When I tried it ( a while ago now) it was the 1.5 features that caused the trouble. I thought it might have settled down by now. Peter --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
Re: Plain old line-breaking
Jeremias Maerki wrote: I can't talk for Luca, but I don't think we have explicit design docs for that part. I think there is some useful content in the mail archives (search for Knuth). Other than that, I realized that the algorithm described in Knuth's Digital Typography is now in our codebase quite literally (although by now with some extensions). I had no trouble tracing back code parts to the book. Understanding the algorithm itself as described by Knuth gets you 80% of the way to start the implementation as I see it. Unfortunately, the book was sacrificed to the weight restrictions. I'll get it mailed over. Peter --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
Plain old line-breaking
Fop-devs, Is there any design documentation about plain old line Knuth breaking, as implemented by Luca? I see lots of stuff in the Wiki about page breaking, but can't see the original. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
Re: [NOTICE] Apache FOP moved from CVS to Subversion (SVN)
Jeremias Maerki wrote: On 25.06.2005 01:34:43 Peter B. West wrote: Jeremias Maerki wrote: Hi Peter On 24.06.2005 04:19:33 Peter B. West wrote: Subversion is no unknown quantity anymore, well maybe on NetBeans. It just takes some time until it gains a better foothold. Nub of the problem. I ask myself the question, Why is the Apache Foundation *forcing* the adoption of Subversion, when Subversion is not even an Apache brand? Looking at the composition of the Board might give some clues. That composition has just changed, of course. It's not the ASF itself forcing the adoption of Subversion, it's mainly the Infrastructure team. Subversion allows the addition of new committers without the need for a shell account. AFAIK this is the main reason. As the ASF grows the Infrastructure team has to somehow manage to keep the ASF alive and as part of that it is planned to stop giving away shell accounts. Subversion proved to be ideal because of (1) its features and (2) the connections into the development team. Probably a few other reasons as well. I recall. I was subscribed to infrastructure@ during much of the time when these decisions were being made. I also recall that prominent names from the Board were active during that discussion. Having worked with Subversion for 18 months now I prefer it to CVS by far. You can always get the sources using the official command-line client that comes with Subversion: http://subversion.tigris.org/ http://subversion.tigris.org/project_packages.html Which is what I had to do with BitKeeper, for which no client existed in NetBeans, Eclipse or any other widely used IDE. My only gripe is facing another learning curve for an SCM product whose basic design has already been superseded by the distributed design of BitKeeper, Monotone, Darcs, etc. Remove BitKeeper from that list. It's not an option anymore. And then I haven't even heard of Monotone and Darcs before. I don't recall any discussion of the possible alternatives to CVS for the ASF. Obviously, if you have never heard of Monotone and Darcs, neither do you. So what criteria are in play when important decisions like this are made within the ASF (and it is the ASF Board which is responsible for decisions which impact the Foundation as a whole)? Anyway, if you look at [1], SVN makes a pretty good impression. The feedback I've seen so far within the ASF was mostly positive to excited, even from some critics. Sure, Subversion is probably not the best tool for Linux kernel developers but it fits the ASF's needs. [1] http://better-scm.berlios.de/comparison/comparison.html Let's put this to rest, the decision has been made and I can't see anyone within the ASF criticize that decision today. Agreed, and it's hardly likely that anyone within the ASF is going to criticise that decision today, is it? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Hi Peter, ..., and Jenni and I are moving to the UK for 12 months at the end of June, ... Well, if you have plans to cross the channel and visit Belgium during those 12 months, be sure to drop me a line. Maybe we can get together for a beer :-) We plan to cross the channel many, many times. Can't wait to have that beer. Cheers, Andreas Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)
Jeremias Maerki wrote: Do you, by chance, intend to visit ApacheCon in Stuttgart in July? It's relatively expensive, isn't it? I don't know what I will be doing at any particular time. It depends on what work is available to me. If you come to Switzerland, tell me! I certainly will. There are a few of you in the area whom I will contact when we pass through. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: Foray's font subsystem for Fop
Victor Mote wrote: Jeremias Maerki wrote: Just to be clear, these are the possibilities: 1. FOP uses FOray-Font (JAR file in lib directory), no license grant necessary, no FOray sources in an ASF repository. This is my preference. 2. FOP forks FOray-Font, license grants are necessary due to ASF policy. I will be happy to provide such a grant. 3. You donate FOray-Font (back) to the ASF, development within FOray stops, FOray uses a JAR from XML Graphics Commons, development continues within the XML Graphics Commons area, license grants are necessary due to ASF policy. This is essentially what I tried to do from within FOP. It failed miserably. I cannot afford to make that mistake again. More to come later by way of answer to your other emails. I have an interest in the future of FOray-Font, so my preference is shared with Victor. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - The atTridged version
Re: Foray's font subsystem for Fop
Jeremias Maerki wrote: On 14.06.2005 17:59:03 Victor Mote wrote: That whole idea deserves more thought and experimentation, and I haven't had time to work on the font system since October. Victor, I have been experiencing similar frustrations, and Jenni and I are moving to the UK for 12 months at the end of June, so I don't expect to have any concentrated development time for a while. Absolutely. It would be great if it could be made to work but I seriously doubt it. At any rate I wish Peter the best of luck with his approach. I hope he'll be a happy customer of our Graphics2D implementations when they are separated in the XML Graphics Commons area. :-) I certainly hope so. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - The atTridged version
Re: Foray's font subsystem for Fop
J.Pietschmann wrote: Jeremias Maerki wrote: Ok, but this assumes that you work in concert with AWT's font subsystem. Well, AWT doesn't provide a way to get the file for a font, but we can at least get an AWT Font from a TTF file. And a Type1 file (Java 5). Java just keeps getting better. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: Foray's font subsystem for Fop
J.Pietschmann wrote: Vincent Hennebert wrote: I was starting to wonder what I could have done wrong so that things turn out that way. Just ignore the bickering for now. There seems to be a law that every Open Source project (or any other reasonably open project for that matter) sooner or later will get people with incompatible personalities, resulting in some mud slinging on mailing lists or worse. Notice the dismissal of one of the core BSD core developers last year, regular flame wars on the Linux Ethernet driver lists including heavy name calling and mutual allegations of incompetence, the fork of Geronimo off JBoss with associated ugliness and so on. No need for you to worry. Let's not forget Linus v. President Tridgell, a dispute with somewhat wider impact. It's almost as bad as proprietary projects, but everything is on public view, everyone gets to express an opinion, and the individuals have real alternatives on how to proceed after disagreements. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: [VOTE] Merge Knuth branch back into HEAD
Jeremias Maerki wrote: Still, we're at a point where we should finally say yes or no to further pursuing the new page breaking approach. Merging the branch back into HEAD means a step back for a few features and on the other side a step forward especially for keeps. I got the impression that the team is pretty much committed to continue on this path and this vote should confirm that. The team has made remarkable progress in this. My congratulations. From the outside, I share the reservations expressed by Jeremias and Simon. It will be an extremely impressive achievement if they are all resolved. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Applying Finn Bock's patch (again) :-)
Jeremias Maerki wrote: So far the most helpful resource for understanding the whole story was Digital Typography by Donald Knuth (chapter 3 only): http://www.amazon.com/exec/obidos/tg/detail/-/1575860104 The chapter in question (Breaking Paragraphs Into Lines) was originally published by Knuth and Plass in Software - Practice and Experience 11 (1981), 1119-1184. Anyone who is interested may be able to obtain a copy of the ogiginal paper more cheaply than the book. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Collapsing border model
Jeremias Maerki wrote: PS: Can someone please beat me? Stick, riding crop, whip, rope, chain or plain old bare knuckles? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: [VOTE] Batik and FOP to migrate from CVS to Subversion
Jeremias Maerki wrote: As announced on the XML Graphics General mailing list I'd like to call for a vote on the migration of both Batik and FOP to Subversion. You can always put the repository in BitKeeper on bkbits.net. It has only the bk command-line and the cosmetically basic (but extremely useful) bk GUI tools, including citool, difftool and 3-way merge. There's no integration that I am aware of with Eclipse or other IDEs, and certainly no integration with NetBeans. This is a pain when doing any refactoring that involves renaming. Basically, you can't do such things within the IDE. So why bother? Try BitKeeper and you'll realize why Linux development moved to bk, in spite of the storm of complaint about using a closed source tool. I haven't used Subversion, only read a little about it, but bk is the best SCM tool I have ever used, by a country mile. It is designed for distributed development. This is actually a serious, though futile, suggestion. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
