Re: [Fwd: Re: cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java Fop.java]
Glen, I put in a vote for Simon. The language thing is confusing, I know. There have been occasions on which the Austrian flag has been flown, or the Austrian National Anthem been played, somewhat inappropriately. But it's en_AU over here; AU because we got in first. Peter Glen Mazza wrote: Also while you've been gone: -- Joerg and Chris are on vacation. -- Simon is currently running for committer [2]--bitte wählen!!! (hmmm...or is it the *Austrians* that speak German? I keeping getting the two mixed up... ;) -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fontconfig
Jeremias Maerki wrote: If that is the case (a big if) might we not be better to move to a more generic form, with translation into each particular form of font specification? I can't tell. I don't see much benefit because the current system already provides most of what FOP needs. A total rewrite may provide more flexibility on the long run but will mean a lot of work which is problematic in FOPs current state. It should be fairly simple to add the two most important missing features to FOP font handling: on-the-fly font discovery and font aliases. I was looking for the correspondence to the Rec (and CSS2) handling of fonts. The generic family set from the Rec includes serif, sans-serif, cursive, fantasy, and monospace. These are the fall-backs. The individual family-names are invoked by the user, possibly in blissful ignorance of what fonts are actually available to a particular renderer. According to the Rec, it is the User Agent's job to build a font database with a full set of information about the fonts it has available, including their family-name and the generic family to which they belong. The parameters for font selection are font-family (in both the broad and specific senses given above), font-style (normal, italic, oblique, backslant), font-variant (normal or small-caps), font-weight (normal, bold, bolder, lighter, 100, 200, 300, 400, 500, 600, 700, 800, 900), font-stretch (normal, wider, narrower, ultra-condensed, extra-condensed, condensed, semi-condensed, semi-expanded, expanded, extra-expanded, ultra-expanded) and font-size (including xx-small, x-small, small, medium, large, x-large, xx-large). It seems to me that, at some point, we have to map from this set of properties to the font characteristics of the renderer in question. Is this what you mean by on-the-fly font discovery and font aliases? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [Fwd: Re: cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java Fop.java]
John Austin wrote: On Mon, 2004-04-12 at 04:33, Peter B. West wrote: Glen, I put in a vote for Simon. The language thing is confusing, I know. There have been occasions on which the Austrian flag has been flown, or the Austrian National Anthem been played, somewhat inappropriately. But it's en_AU over here; AU because we got in first. And the Austrians don'd call it Austria ... Isn't it Osterreich Hmmm... Yes, of course. In that case, we had better claim OZ as well, and the Osterreichers can have OS. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Messages to fop-dev black-holed?
Noel, Where do we find out what's involved? Peter Noel J. Bergman wrote: Only Dw. Looking at http://xml.apache.org/fop/team.html, I'd guess that he is doing it only because no one else is. Personally, I'd like to see at least two active members of the team handling moderation for the list. From: Peter B. West [mailto:[EMAIL PROTECTED] Thanks Noel. Mailbox full of garbage, no doubt. Thank you Bill. I shall re-subscribe. Do we have a moderator? Noel J. Bergman wrote: Is it possible that my messages to fop-dev are being black-holed? They are pending a moderator. You are not currently subscribed to fop-dev. your e-mail address was removed due to bouncing. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: The new logging framework and Java 1.4 logging
Glen, As I read the docs, I can have a Log4J, a JDK1.4, or a SimpleLog, depending on 1) my property file or service discovery setup, if any, or the default factory discovery method. The default method (LogFactoryImpl) will 1) give me a Log4J logger, if available 2) give me a 1.4 Logger, if available 3) give me a SimpleLog. If I get the default SimpleLog, which implements Log, I can have SetLevel, but if I use the 1.4 logger, I do not have access to the corresponding 1.4 facility. This looks like an oversight in the definition of the 1.4 logger. I'll subscribe to the Commons lists and check this. Peter Glen Mazza wrote: I think it's just setLevel() that you're looking for: http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog.html Peter B. West wrote: I see that you have the move to commons-logging. I was encouraged by this because of the support for 1.4 logging, which I have started to use in alt-design. When I looked at modifying the existing alt-design code to use common-logging, however, I could find no way to set the logging level on an existing logger, as there is, e.g., in SimpleLog. I can specify a default level in commons-logging.properties (I assume - I haven't tried it), but if I want to dynamically change the level in response to the options with the existing implementation, I'm stumped. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: The new logging framework and Java 1.4 logging
Glen, I noticed that, but it seems to rather defeat the purpose of having a common wrapper in the first place. It means that at various points in my code, I have to drop out and start looking at the particular implementation. I suppose it is still an advantage, in that *most* of the code will still be able to log using common calls, but it is not tidy. Peter Glen Mazza wrote: There appears a getLogger() that will take you to the native java.util.logging instance: http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/Jdk14Logger.html From there, you should be able to call the native setLevel() of the 1.4 logger: http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html#setLevel(java.util.logging.Level) -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: The new logging framework and Java 1.4 logging
There is a release candidate for commons-logging v1.4, which includes support for Lumberjack logging, i.e., Java1.4 style logging for 1.3 environments. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [VOTE] Simon Pepping for Committer
+1 -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: The new logging framework and Java 1.4 logging
One of the virtues of 1.4 logging is that (subject to security policies, I think) the level can be set dynamically. If I run a *n*x shell script, I can arrange to catch signals and, among other things, reset the logging level on the fly. Java logging should offer the same capability, especially in embedded situations. If you are getting some strange results from production facility, it would be useful to be able to start increasing the logging level in order to get more information, and to turn it back down when you have what you want. 1.4 loggers are typically application specific, and will generally be named accordingly, e.g., org.apache.fop.Fop. This also allows you to have loggers for separate components - org.apache.fop.render.awt, and you can fine-tune your logging by package, class or even method. That's my reading, anyway. Peter Glen Mazza wrote: For some reason interface Log (common to all the logging types) does not have a setLevel()--somehow I think that was intentional, however. After all, should FOP actually be setting the logging level? For *embedded use*, that is done by the user--they choose the logger and the level they desire, and feed it to FOP via Driver.setLogger(). I'm not sure FOP should be altering that level, because that logger could be used for many other things in the user's application. If there's messages they don't receive that they actually want, they should adjust the logger on their end accordingly. (OTOH, for command-line usage, this may be another story.) -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
[Fwd: Re: cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java Fop.java]
Resending, as I had been un-subscribed due to mail bounces. Glen et al, I have been severely distracted over the past couple of weeks, and I seem to have lost a good deal of mail in the process. Can you give me a reference to the patch. Sorry I didn't get around to replying to a question of yours about the effects on alt-design integration of a patch you wanted to apply. Peter [EMAIL PROTECTED] wrote: gmazza 2004/04/08 20:05:40 Modified:src/java/org/apache/fop/apps CommandLineOptions.java Fop.java Log: 3/4ths of Simon's patch committed at the moment, with minor changes made. Revision ChangesPath 1.17 +19 -37xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Fontconfig
Jeremias et al, In connection with our recent discussions concerning font handling, I looked at the contentious fontconfig system driven by Keith Packard. The user documentation at http://pdx.freedesktop.org/~fontconfig/fontconfig-user.html includes: quote Font Properties While font patterns may contain essentially any properties, there are some well known properties with associated types. Fontconfig uses some of these properties for font matching and font completion. Others are provided as a convenience for the applications rendering mechanism. PropertyTypeDescription -- family String Font family name style String Font style. Overrides weight and slant slant Int Italic, oblique or roman weight Int Light, medium, demibold, bold or black sizeDouble Point size aspect Double Stretches glyphs horizontally before hinting pixelsize Double Pixel size spacing Int Proportional, monospace or charcell foundry String Font foundry name antialias BoolWhether glyphs can be antialiased hinting BoolWhether the rasterizer should use hinting verticallayout BoolUse vertical layout autohintBoolUse autohinter instead of normal hinter globaladvance BoolUse font global advance data fileString The filename holding the font index Int The index of the font within the file ftface FT_Face Use the specified FreeType face object rasterizer String Which rasterizer is in use outline BoolWhether the glyphs are outlines scalableBoolWhether glyphs can be scaled scale Double Scale factor for point-pixel conversions dpi Double Target dots per inch rgbaInt unknown, rgb, bgr, vrgb, vbgr, none - subpixel geometry minspaceBoolEliminate leading from line spacing charset CharSet Unicode chars encoded by the font langString List of RFC-3066-style languages this font supports /quote I have also, as I noted previously, looked briefly at the way fonts are defined in Java. Would I be correct in surmising that the current manner of defining fonts is derived from Adobe's methods for PDF and PS? If that is the case (a big if) might we not be better to move to a more generic form, with translation into each particular form of font specification? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
The new logging framework and Java 1.4 logging
Glen, I see that you have the move to commons-logging. I was encouraged by this because of the support for 1.4 logging, which I have started to use in alt-design. When I looked at modifying the existing alt-design code to use common-logging, however, I could find no way to set the logging level on an existing logger, as there is, e.g., in SimpleLog. I can specify a default level in commons-logging.properties (I assume - I haven't tried it), but if I want to dynamically change the level in response to the options with the existing implementation, I'm stumped. Does anyone know how to do this? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Web Start
Fops, Does anyone have any detailed knowledge of Web Start? It occurred to me that it may be a way to resolve some of the licensing issues we (and other projects) are running into. Any educated thoughts on the matter? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Another licensing issue
Jeremias et al, I would like ti use the Unicode Character Database as a source for names of characters. At the moment, ...fonts.Glyphs contains a static table of String pairs containing the Unicode character and its name, respectively. The names are not the Unicode Character Database names, and I thought it might be a good idea if they were. However, there seems to be no way to get the canonical UCD name from Java, although java.lang.Character and java.lang.Character.UnicodeBlock have extensive support for various characteristics of the UCD. The problem with deriving the names from the UCD is another one of licensing. Any ideas about how we might approach this? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Web Start
Glen, I was thinking that with Web Start, we would not need to hold contentious files in the FOP repository. All we need is a reliable location for them, with appropriate verification. Then the process of installing FOP can transparently (or with loud warnings) include files from non-Apache sources. Peter Glen Mazza wrote: I didn't know about Web Start--looks very interesting [1], but I don't see where this would help FOP w.r.t. licensing--we would still be redistributing L/GPL and other license-incompatible software, even if automated by Web Start, correct? Glen [1] http://www.javaworld.com/javaworld/jw-07-2001/jw-0706-webstart.html -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Antwort: Web Start
Arnd, Keeping in mind that I am utterly ignorant of a lot of these issues, and am tossing straws in the wind, see comments below... [EMAIL PROTECTED] wrote: Hi Peter, we use Web Start in a customer project. It's a good solution to deploy Java applications as a JAR file, even with native code and such. Some caveats: -The security manager can get in your way if you want things like filesystem access. You have to sign your jar and each user has to accept your signature once per application. If the once per application meant once per Fop installation, that would be OK. Can the user allow us file system access once the signature is accepted? - You cannot catch uncaught exceptions in JNLP applications. This is useful for GUI applications, so you can catch and for example log these exceptions. With JNLP, AWT/Swing creates its own thread group so you're out of luck there. Maybe not an issue for fop. I'd have to think about the implications of this. Drawing a blank at the moment. - Only comes with JRE 1.4 by default, and older WebStart version are quite buggy in my experience. This is a show stopper while we are supporting 1.3. So far I cannot see how exactly WebStart would be useful for FOP regarding licensing stuff, because your sources for parts like hyphenation libs still need to be JNLP jars, so you still need someone to actually provide these jars and thus take responsibility regarding legal issues. As for as I see it, you don't gain anything. Let's say, for example, that we approach a TeX distribution with a request that we be allowed to download the TeX hyphenation files, as modified for use with Fop. If they are OK with that, we generate a jar file with the hyphenation files, including the original copyright (and possibly notes about the conversion being done under the auspices of Apache) and drop it on the CTAN servers. Alternatively, we simply jar up the original TeX files, and include a conversion process in the installation. The files are not coming from an Apache server, and they do not carry the Apache license (except for perhaps a Parts copyright... notice). It is a convenience to our users that we download such files transparently from another source on installation. But if you have something more concrete in mind, please feel free ask more concrete WebStart questions. Thanks Arnd. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Another licensing issue
Jeremias, The penny just dropped about the names of the Unicode characters; they are the Adobe Glyph List and the Zapf Dingbats Glyph List names of a subset of Unicode characters. Won't we at some stage need to generalise support for a wider set of glyphs? Or is that entirely a matter for user-defined fonts? Looks as though I'll have to look at user fonts. Peter Peter B. West wrote: Jeremias et al, I would like ti use the Unicode Character Database as a source for names of characters. At the moment, ...fonts.Glyphs contains a static table of String pairs containing the Unicode character and its name, respectively. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
InputHandler - re baseURL commits
Glen at al. One of the things I noticed when I was looking for ways to bring the apps classes of alt-design and HEAD closer together was that the createParser method seemed to belong in InputHandler, because it is required by both subclasses. Any reason why it isn't there? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: InputHandler - re baseURL commits
Glen Mazza wrote: (Hmmm...I'm supposed to be learning Cocoon right now, but am already suffering FOP-withdrawal. Apache's got me good... ;) [just removed the namespace-prefixes issue you were mentioning earlier, btw.] I noticed that. FOFileHandler.createParser() is just a simple static function that generates a parser. It can be placed in any class, and is not something that needs to be inherited. (Actually, the hyphenation class' PatternParser also creates a parser, although it could use the one in FOFileHandler as well.) InputHandler has a abstract getParser() method which is used by Driver et. al. This method *does* need to be overridden in each of the base classes, and of course it is. It just so happens, but is not necessarily required, that the current implementation of XSLTInputHandler uses the createParser() of FOFileHandler for its implementation of getParser(). This is just an implementation detail. XSLTInputHandler's getXMLFilter() (called by its getParser()): // Create an XMLReader. XMLReader parser = FOFileHandler.createParser(); I preferred the direct reference to the FOFileHandler method (as opposed to simple inheritance) for reasons of documentation: this way, we're clearly stating that XSLTInputHandler is using FOFileHandler's parser as part of its XMLFilter. (Also, at the time I was doing this, I was planning on having a DOMInputHandler--but was running into difficulty doing so--that I believe would have caused a createParser() to not have been relevant in the base class.) Glen, Thanks for the explanation, and thanks for surfacing. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fonts and Document
Jeremias, See below... Jeremias Maerki wrote: The font subsystem is still far from finished. It's still quite complex to understand, unnecessarily so IMO. My font source idea still need to be implemented... Let's see if I can pull together some connectors. I agree that it is complex to understand. As you've seen the Document class is a central class in font handling. It currently (not in my ideas) provides direct access to font metric information and to the list of fonts actually used in a rendering run (we don't always want to embedd them all). The setup of all fonts is done in the FontSetup class where the base 14 fonts are defined. Additionally, custom fonts are added there. But the custom fonts are mostly renderer-dependant, so at the moment, some font setup also takes place in PDFRenderer for example. See PDFRenderer.configure (which can build custom font information using an Avalon Configuration object using a helper method from FontSetup) and PrintRenderer.setupFontInfo which actually triggers the font setup. The fonts get registered with the Document object and subsequently is available to the layout engine. One of the complications is that Document wears so many hats. I see a Document object referred to by the variable fontInfo in one place, and by the variable foTreeControl in another. Document implements FOTreeControl, FOTreeListener and AreaTreeControl, so the foTreeControl variable looks deliberate, but the fontInfo may be a hangover. In any case, wouldn't it be clearer to have such functions realized in separate objects which are created and managed by Document? Most font classes in the fonts package deal with the different font formats (single byte und unicode, base und custom...). There's also a difference in audience: The layout needs different information (metrics in particular) than the renderers (primarily information for using and embedding the font in the target format. This is my first close look at fonts, and I have browsed the java.awt.Font and java.awt.FontMetrics classes and the java.awt.font package. In itself, this bundle of interfaces and classes is complex, but the nub of it seems to be the 2D font classes. At first glance, there is a close connection between fonts, glyphs, strings, text attributes and line layout, all covered in these classes. I am wondering if we cannot use the Java model as a basis for FOP's line area layout API. The discussion in http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-fonts.html#wp66677 contains a discussion of implementing a custom text layout mechanism to enable features like kerning and ligatures. My intention is to develop the initial alt-design layout using AWT rendering. I assumed that I could get usable testing output more quickly that way, without having to delve into PDF. My comments may simply be conditioned by that perception. I'm not talking about adopting 1.4 (and 1.5 when it is stable), but using the API model where it provides appropriate methods for laying out text. One implication of that would be a fairly intricate interaction between all the phases of FOP, involving the font details provided by the renderer. However, I recall that Hansuli Anderegg has been working along these lines for some time now. Btw, what search keys should I use to recover details of your font model from the archive, assuming there are differences between your model and the wiki? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: temporarily inactive
Thanks for the support Ali. Are you a Fop user or a potential developer? Peter Ali farahani wrote: Oh guys! This is some sort of Matrix right? I mean, is there any other world rather than this(Virtual)!? I hope Glen lead us to that world! Best Regards One of your fans -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: temporarily inactive
Glen, Jenni is pleased to hear that you have a life in the non-virtual (read real) world. Wishes the same for me. Enjoy yourself. Come back soon. Peter Glen Mazza wrote: Team, I'll be taking a few weeks off the project, there's some things I want to study and get out of the way right now. I'll be back to coding soon! -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: namespace-prefixes
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: ... That is, I would turn allow the namespace-prefixes feature to remain in its default 'false' state, but make sure the parser is namespace aware. I don't know that there is any reason for us to collect prefixes, This is somewhat outside my knowledge, but one difference, I believe, between HEAD and Alt-Design is the former's ability to have user-configured, run-time add-in element mappings. (I think we have one for MathML and another one for something else in our examples.) Given that, could that be HEAD's reason for needing to collect prefixes? I don't think so. Prefixes are a shorthand convenience - they must be supported by underlying full namespaces. Prefixes are unstable, in that the same3 prefix can signify completely different namespaces at different points in the file, IIUC. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Wiki Migration and other issues
Christian Geisert wrote: Christian Geisert wrote: J.Pietschmann wrote: [..] Should we wait for the Apache XML reorganization to complete or should we rush ahead and create out own Wiki already? +1 for the new wiki It has a nicer look, supports XML export and we can have 'commit messages' to fop-cvs Others opinions? Considering this a strong recommendation from infrastructure I'd say we migrate to the new wiki (of course if there are no -1s) There's a tool for automatic converting content from the old wiki and if this doesn't work I'll volunteer to do it manually. Ok by me. From what I've seen on infrastructure@, there may be some post-conversion tidying to do. +1 Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: namespace-prefixes
Elliotte Rusty Harold wrote:
At 12:56 PM +1000 3/4/04, Peter B. West wrote:
...
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
return factory.newSAXParser().getXMLReader();
...
What I ask on reading this code is why you're using SAXParserFactory at
all? SAXParserFactory is a Sun class they invented to fill a hole in SAX
1.0. It's unnecessary in SAX 2.0. SAX2 apps should use XMLReaderFactory
instead, which has the correct defaults you want in the first place. It
would look something like this:
protected static XMLReader createParser() throws FOPException {
try {
XMLReader parser = XMLReaderFactory.createXMLReader();
return parser;
} catch (SAXException se) {
throw new FOPException(Could not find a parser. Make sure the
+ system property is set);
}
}
That's off the top of my head so it may not compile, and there are ways
to look for alternative parsers if you don't find one immediately (See
http://www.cafeconleche.org/books/xmljava/chapters/ch07.html#d0e9994 )
but you get the idea.
Elliotte,
I think this might be because the HEAD developers were moving to a JAXP
implementation, and SAXParserFactory is still in the 1.4
javax.xml.parsers package, which, AIUI, is what one is supposed to use
for JAXP-compatible applications. I don't know much about JAXP, so this
could be wrong.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
fop.xconf
Fops, What's the intention for fop.xconf? Is it to be processed by the user agent? What about user configuration? Have these things been decided yet? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
namespace-prefixes
Fops,
In HEAD, ///apps/FOFileHAndler.java contains the following:
protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
factory.setFeature(
http://xml.org/sax/features/namespace-prefixes;, true);
return factory.newSAXParser().getXMLReader();
} catch (SAXNotSupportedException se) {
throw new FOPException(Error: You need a parser which
allows the
+ http://xml.org/sax/features/namespace-prefixes;
+ feature to be set to true to support
namespaces, se);
I would be inclined to modify that to:
protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
return factory.newSAXParser().getXMLReader();
} catch (SAXNotSupportedException se) {
throw new FOPException(Error: You need a parser which
allows the
+ http://xml.org/sax/features/namespaces;
+ feature to be set to true to support
namespaces, se);
That is, I would turn allow the namespace-prefixes feature to remain in
its default 'false' state, but make sure the parser is namespace aware.
I don't know that there is any reason for us to collect prefixes,
rather than simply allowing the parser to keep track of the namespaces
in effect and return namespace and local names. That's what I have done
in alt-design without any regrets so far.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Thanks Jeremias
Thanks again, Jeremias, for all of the licensing housekeeping. I'm sorry I didn't get around to giving you a hand with this. Does anything (apart from the hyphenation mess) remain to be done? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Newbie Commiter Questions
Chris, I suspect that the problems with SSH2 might be to do with the way Putty represents SSH2 keys. The format of the Putty file is different from the openssh format, even though they contain compatible data. I think Putty has an option to import openssh format keys, and I seem to remember using this option to set up SSH2 keys that worked between Linux and Windows. Peter Chris Bowditch wrote: Jeremias Maerki wrote: I've had my problems with using SSH2. I finally tried SSH1 and it worked. I suggest you create a SSH1 key pair and retry with this. Thanks for the fast response Jeremias. I have managed to get SSH1 working. There are two ways you can work with putty. Either you create a tunnel for CVS which has the benefit that the connection is always there as soon as you have connected to the server. Yes I'm creating a tunnel with Putty and pointing WinCVS to localhost. The other way is to use plink which has to build a connection everytime you access CVS. Select SSH authentication in WinCVS and specify the full path to plink.exe as SSH client. You need to have Putty Password agent running for that. Tell me if you need more info. Good luck! I have managed to update the team page now. Thanks -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Preferences
Peter B. West wrote: ... We could address the JVM version issue by wrapping the java.util.prefs stuff in org.apache.fop.prefs or ...configuration classes which mimic .util.prefs by a thin wrapper around the latter classes, and providing for 1.3 compatible versions to be written. The availability of 1.4 could easily be tested at run-time, and the appropriate switch set for use in org.apache.fop.prefs, reducing the build complexity. Don't mind me... The build complexity will be same as at present, requiring 1.3 and 1.4 components to be shifted in at build time. The passing fantasy about a run-time switch afflicts me every now and then. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [VOTE] Clay Leeds for Committer
Andreas L. Delmelle wrote: -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] So let me start off the voting: +1. No need to think this over: +1. +1 -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Preferences
Looking at merging in the HEAD options processing into alt-design, I took a look at XML-Commons CLI, which seems to tidy up options processing quite nicely. However, I also took another look at both the Properties and Preferences APIs. It seems to me that the current CLI options processing could be replaced by a set of command-line property definitions. This would be more in keeping with the assumptions of Java. One immediate problem is that any line-length restrictions would be sooner violated if we were using property definitions. Not being familiar with the requirements of application servers and embedded FOP, I can't comment on the implications in that environment. If we do go that way, however, it brings up the issue of java.util.prefs again. It seems to me that a naive implementation of the API could use the existing config and userconfig files to provide the system and user persistent stores, at least for reading. java.util.prefs requires that the backing store be writable, however, and I don't know how this would fit in a server environment. (This requirement can probably be circumvented at run-time by assuming that the backing store becomes unavailable after the initial read: prefs is designed to be robust in the face of backing-store unavailability.) We could address the JVM version issue by wrapping the java.util.prefs stuff in org.apache.fop.prefs or ...configuration classes which mimic .util.prefs by a thin wrapper around the latter classes, and providing for 1.3 compatible versions to be written. The availability of 1.4 could easily be tested at run-time, and the appropriate switch set for use in org.apache.fop.prefs, reducing the build complexity. For now, I will just drop org.apache.commons.cli in and use it for options processing. What do folks think about these issues? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fwd: ASF Board Summary for February 18, 2004
Don't speak too soon, Glen. I'll have words to the Board about this. If the Board were concerned about the legal ramifications, they would be obliged to mandate the removal of author tags. Why don't they? Until they demonstrate otherwise, I'll assume that the *real* agenda is ...social issues dealing with collaborative development, and ignore the Board's discouragement. Peter Glen Mazza wrote: Score (another) one for Jeremias... ;) --- Greg Stein [EMAIL PROTECTED] wrote: - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags - it is quite acceptable and encouraged to recognize developers' efforts in a CHANGES file, or some other descriptive file which is associated with the overall PMC or release rather than individual files. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] snip / The borderline cases may be very much in the minority (and must be, judging by the degree of usage that FOP gets now) but they must be taken into account in the design of the solution. If we go for the low-hanging fruit and then discover that the ladder is too short we end up back in the workshop. I understand, but what I'm referring to is (taking your analogy a bit further): You want an 'extensible' ladder which you can keep short for the low-hanging fruit, and extend to reach the higher ones. If you get to a tiny tree with a huge ladder, you're going to be cursing yourself anyway as your big ladder will make the job more difficult, IYKWIM (--you might not even need that ladder, but still you carried it all the way down there...). The point that would concern me is an API that forces the most trivial and common cases into a processing-model that is actually meant to accommodate rather complicated structures. So you'd end up having an overhead in 95% of the cases, overhead which strictly speaking is meant to occur in only 5% of the possible situations. If it results in (virtually) no overhead at all, this point of course dissolves totally... the ladder is then extensible in just the right way. There's a lot of subjective judgement in making such calls, which is why it's useful to have a number of different opinions kicking ideas around. I wasn't thinking of the buffers. The re-usability of the buffers is only relevant to static-content and markers, so I don't see that as a major issue, and would expect to keep the static-content buffers for a page in memory for the life of the page-sequence. Markers are a bit more problematical, and may well benefit from some transparent serialization. Sorry, I'm still a bit misguided, it seems. This part, I already got, but... I was thinking more of the historical parts of the FO and Area trees. ... putting quotes around there is to beg the question, so, would that be the parts that have already been processed in some way? Yes. Candidates would be FOs and areas associated with pages containing forward references, and, in general such objects associated with the current page sequence, from the point of view of possible layout optimisation. At one stage I considered linking all nodes in the FO tree with reference objects, but I was concerned about the extra layer of reference objects and their impact on memory and performance. However, when we get parallel FO tree, Area tree and rendering working it may pay dividends. I find the language of the java.lang.ref package confusing, but I think that phantom references open the possibility of performing serialization on demand, when the object is queued for GC. Can you elaborate a bit on this? AFAICT, the actual referent of a phantom reference is itself unreachable through the reference object (the ref's get() method always returns null), so you could indeed test via isEnqueued() whether or not the referent of a phantom reference is queued for GC, and then...? A soft reference at least would allow to get() the object and do something with it or make it do something with itself before actually clearing the ref. As I say, I find the language confusing, but it seemed to me that, as long as the object being GC'd contained enough information to determine its origins, when it found its way onto the reference queue for disposal the thread responsible could serialize it just before it was destroyed, and store the information required for its recovery in the appropriate place. The same may be achievable using the other reference types. Whether the imprecations against finalizers apply also to phantom reference finalizers I don't know. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Thanks Andreas. Yes, I disagree, but then, so does the spec. What information *should* do is not terribly relevant. We need to work out and express what information *must* do to get this thing working. Voila! Without worrying too much about textbook 'should'-stuff... It is after all *XSL*-FO, so I guess the basic compliance rule is also for FO processors: 'the order of the processing events doesn't matter at all, as long as the produced output is correct.' [Me:] ... Would it really be worth a shot to change the design there, and flip a switch? Throw the FOTree away and just fill up the AT and re-use that? Or process the minimal relevant parts of the FO and Area trees in parallel. That is what I am working towards. I believe that page-at-a-time layout with just in time processing of the FOs is possible. Given that, both FOs and Areas can be kept alive while required. (I haven't given any thought to rendering.) Indeed. When I began thinking about 'borderline-cases', it became clearer that situations where you need to wait for more than one page to complete the layout are rather exceptional anyway, so it's most likely the better option to treat them as what they are: 'an exception to the general processing flow' (--IOW, not *all* theoretical possibilities implied by the definitions in the spec should be covered by the *basic* processing framework). The borderline cases may be very much in the minority (and must be, judging by the degree of usage that FOP gets now) but they must be taken into account in the design of the solution. If we go for the low-hanging fruit and then discover that the ladder is too short we end up back in the workshop. Note that forward references are always going to be a problem, but that a combination of weak/soft/phantom references and serialization should keep memory requirements manageable. That's where your producer-consumer buffers step in, right? So.. by 'minimal relevant parts' you actually mean something as 'reduced skeletons of subtrees' that in themselves provide a way to pull the events generated by their descendants from the buffer, without themselves actually holding a reference to the descendants, so while the ancestor is being kept alive, the descendants can be happily collected by our friend GC if no longer used by another process, while the ancestor remains at our disposal to re-pull the same events from the buffer if/when they are needed. Is this close? I wasn't thinking of the buffers. The re-usability of the buffers is only relevant to static-content and markers, so I don't see that as a major issue, and would expect to keep the static-content buffers for a page in memory for the life of the page-sequence. Markers are a bit more problematical, and may well benefit from some transparent serialization. I was thinking more of the historical parts of the FO and Area trees. At one stage I considered linking all nodes in the FO tree with reference objects, but I was concerned about the extra layer of reference objects and their impact on memory and performance. However, when we get parallel FO tree, Area tree and rendering working it may pay dividends. I find the language of the java.lang.ref package confusing, but I think that phantom references open the possibility of performing serialization on demand, when the object is queued for GC. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Finn Bock wrote: [Peter B. West] Finn, When I apply your most recent patch (10366) against a cvs updated HEAD tree and attempt to compile, I get the following: [javac] /usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: After applying the patch (10366), the following files should be removed: src/java/org/apache/fop/fo/properties/LinearCombinationLength.java src/java/org/apache/fop/fo/properties/MixedLength.java Does anyone know how to include a file-remove in a patch? From 'man patch' on linux: You can create a file by sending out a diff that compares /dev/null or an empty file dated the Epoch (1970-01-01 00:00:00 UTC) to the file you want to create. This only works if the file you want to create doesn't exist already in the target directory. Conversely, you can remove a file by sending out a context diff that compares the file to be deleted with an empty file dated the Epoch. The file will be removed unless patch is conforming to POSIX and the -E or --remove-empty-files option is not given. An easy way to generate patches that create and remove files is to use GNU diff's -N or --new-file option. From 'man diff' on linux: -N --new-file In directory comparison, if a file is found in only one direc- tory, treat it as present but empty in the other directory. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
Finn, Nice. The parser, of course, looks after all of the expression-ordering questions for you, and you have only to collect the unresolved items. I'll adopt this for alt-design. Peter Finn Bock wrote: [Peter B. West] Can you describe your expression tree in more detail? The line above is most likely the toString() on the expression that is the result of a start-indent calculation from [5.3.2]. Each set of parens represent an algebra operation node in a (mostly) binary tree. The expression above is actually stored like this. v | +-ADD | +--0mpt | +--ADD | +--0mpt | +--ADD | +--ADD | | | +-- 4000mpt | | | +-- %20 of REFERENCE_IPD | +-- 0mpt The tree is created lazily during the evaluation of expression in the property parser. If both the operands to an operation are absolute, the operation is performed at parse time, but if either one of the operands are relative values, an operation-node is created. The operation node is also considered to be a relative value, so the next operation that involves an operation node will always create a new operation node. (Note to self: Perhaps it is worthwhile to detect if one of the operands in a ADD and SUB operation is 0? It would perhaps reduce memory for the majority of start-indent expressions). A node on the operation tree is represented by an instance of fo.expr.RelativeNumericProperty. The code that creates the tree is located in NumericOp and it is called from the PropertyParser. When a property is retrieved by the LMs, it is the final call to Length.getValue() or Numeric.getNumericValue() that triggers the evaluation of the operation tree. At that time the REFERENCE_IPD value should have been assigned by the LMs to one of the parent fo:elements. regards, finn -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Test - please ignore
-- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Re-sending due to mailer problems. Peter Original Message Subject: Re: [PATCH] Support for percentages and table-units Date: Thu, 19 Feb 2004 12:48:59 +1000 Andreas L. Delmelle wrote: -Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] In my view FOP consists of a number of subsystems that are ordered from upstream to downstream. The FO tree is the most upstream system, the area tree (or objects that are constructed by a renderer) is the most downstream system. Indeed, but... Information should flow downstream, not upstream. (Hmm. Isn't there an Aussie in this house who disagrees? Callbacks, Peter? ;) Nah, bad example...) Thanks Andreas. Yes, I disagree, but then, so does the spec. What information *should* do is not terribly relevant. We need to work out and express what information *must* do to get this thing working. ... Basic point: the preferred direction of the information flow depends (almost entirely) upon the relationship between the up- and downstream events that is being Yep. (Even without the end of the sentence.) You are IMO very correct by stating that 'if the Layout info can be reused, so can the AT and the renderer', however, if I interpret correctly, the latter two are designed to dispose of their created objects ASAP. The downstream objects hold a reference to the upstream ones, not the other way around --unless you have a way out of there, as long as a certain page-sequence is referenced, the entire Layout/AT/Renderer structure would exist in memory, which can get .. quite large even for moderately sized documents. Would it really be worth a shot to change the design there, and flip a switch? Throw the FOTree away and just fill up the AT and re-use that? Or process the minimal relevant parts of the FO and Area trees in parallel. That is what I am working towards. I believe that page-at-a-time layout with just in time processing of the FOs is possible. Given that, both FOs and Areas can be kept alive while required. (I haven't given any thought to rendering.) Note that forward references are always going to be a problem, but that a combination of weak/soft/phantom references and serialization should keep memory requirements manageable. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
Re-resending... Original Message Subject: Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units Date: Fri, 20 Feb 2004 08:05:20 +1000 Simon Pepping wrote: I like the patch and the way RelativeNumericProperty holds and evaluates an expression tree (except my different preference for storing layout information, as discussed). This is really nice and works well: v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt) Finn, Can you describe your expression tree in more detail? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Re-resending... Original Message Subject: Re: [PATCH] Support for percentages and table-units Date: Fri, 20 Feb 2004 19:07:06 +1000 Finn Bock wrote: [me] If an expression reference another expression in a parent fo, the parent fo expression must be evaluated against the LayoutContext that was in effect for the parent fo and *not* against the child fo LayoutContext. fo:block id=a border-start-width=10% fo:block id=b border-start-width=inherit /fo:block /fo:block It must be the LayoutContex for 'a' that is used when we evaluate the 10% even when we call: propertyList.get(PR_BORDER_START_WIDTH).getValue(lc) with the layout context for 'b'. [J.Pietschmann] Well, I used to believe the 10% has been evaluated already, and the inherited property can grab the absolute value immediately. If it is evaluated already where would the evaluated value be stored? In the propertyList (aka the FO tree)? And then the value should be reverted to the expression when the base value changes due to breaks. Storing the resolved value would IMO remove all the benefits from passing in a context parameter to getValue(). Perhaps it can be done that way too, but it is very different from my proposal. In principle, no area-based percentage can benefit from a one-off resolution until all of its children have been fully laid out. The children inherit the computed value, but that value may change during the layout life of the parent in question. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Re-resending...
Original Message
Subject: Re: [PATCH] Support for percentages and table-units
Date: Fri, 20 Feb 2004 21:20:52 +1000
Finn,
When I apply your most recent patch (10366) against a cvs updated HEAD
tree and attempt to compile, I get the following:
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60:
org.apache.fop.fo.properties.LinearCombinationLength is not abstract and
does not override abstract method getValue() in
org.apache.fop.datatypes.Length
[javac] public class LinearCombinationLength extends LengthProperty {
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:96:
cannot resolve symbol
[javac] symbol : method setComputedValue (int)
[javac] location: class
org.apache.fop.fo.properties.LinearCombinationLength
[javac] setComputedValue(result);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:64:
org.apache.fop.fo.properties.MixedLength is not abstract and does not
override abstract method getValue() in org.apache.fop.datatypes.Length
[javac] public class MixedLength extends LengthProperty {
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:89:
cannot resolve symbol
[javac] symbol : method isComputed ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] if (!l.isComputed()) {
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:93:
cannot resolve symbol
[javac] symbol : method setComputedValue (int,boolean)
[javac] location: class org.apache.fop.fo.properties.MixedLength
[javac] setComputedValue(computedValue, bAllComputed);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:109:
cannot resolve symbol
[javac] symbol : method resolveTableUnit (double)
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] ((LengthProperty)
e.nextElement()).resolveTableUnit(dTableUnit);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:136:
cannot resolve symbol
[javac] symbol : method asNumeric ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] numeric = l.asNumeric();
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:139:
cannot resolve symbol
[javac] symbol : method asNumeric ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] NumericProperty sum =
numeric.add(l.asNumeric());
[javac]^
[javac] 8 errors
Is there a patch I have missed. I tried applying the earlier patch
first, but then the second patch is reported as already/applied/reversed.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: FOP report
Jeremias, Berin, et al., Comments below. Jeremias Maerki wrote: Hmmm. I don't think the PMC needs to get involved. Looking at it from a distance this was primarily a disagreement between two people on technical/design issues that somehow couldn't be resolved. One of the two, Victor Mote, decided to give up because he would rather go away than to be the guy that everyone wishes would go away (his words, not my impression). He probably overreacted a bit. I agree that the PMC does not need to get involved. By extension, then, neither does the Board. The issues were resolved within FOP, and resulted in what I consider a regrettable decision by one committer to leave. There was no peer pressure for this outcome. Some background: Fact is that the whole FOP team was exchanged during the last two years. Almost. I've been involved since the beginning of 2001, and a committer for a little over two years now, I think. Joerg, Jeremias and I became committers at the same time, so we had varying degrees of prior involvement. None of the old committers is still active though one or two are still injecting a comment from time to time. We have a heavy decision to carry on taken over two years ago (freezing the old maintenance branch and doing a redesign of FOP). I guess the committers are only now really getting used to all the code in FOP and getting into a position to really bring on the design. Amen. Then we've got the problem that there are some strong personalities among the comitters which doesn't make things easier. Take the mailing list as suboptimal communication platform into the equation and you got the problems together. I myself was pretty close to quitting recently but decided to calm down and to concentrate on investing my very little time still available to FOP in a productive way because I've already invested so much of my free time into FOP that I simply can't let go. I'd like to hear more about your thinking on this and your later comment about the unhealthiness of the team, probably on the fop-dev list, Jeremias. I'm not very good in this sort of thing especially since English ist not my primary language and I know that my intentions sometimes don't make it 100% to the other side. I hope I haven't put any more oil into the fire by writing this. If Peter disagrees with my view of the things I'd like him to chime in. For any details I'd like to point to the fop-dev mailing list archive (the whole thing happened around 2003-12-17). So. Peter and the other PMC members, do you think we should change anything about my report about FOP? I thought, this was important to mention but I don't think this needs any intervention right now as I know that some (or at least one) high-ranking Apache people are listening into the conversions over in FOP-land which I'm grateful for. Maybe infighting wasn't the best word but I took it as such a few times during the last months. I don't consider the FOP developer community a healthy one, especially compared to others here at the ASF, but I also haven't given up hope. We're all struggling for free time, no big companies backing us up anymore. Perhaps infighting over technical/design issues would be more precise. If you saw it as infighting, it's fair enough to describe it that way. I'm interested also in the comment about the lack of backing. What backing were we receiving previously? As to free time, I'm now working outside the industry, on a part-time/casual basis, and I like the situation. Working full-time in IT makes too heavy demands on my concentration to be able to devote the necessary time to FOP, which, as you point out, is extremely demanding. The situation I am in now gives me more time the freedom to do my design and coding the way I want to. That comment has wider application than FOP. On the positive side, the recent increase in activity includes a lot of cross-fertilization from alt-design to HEAD, which seems to have been received very well by everyone concerned. Perhaps this should be mentioned to balance concerns about Victor's departure. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: PMC representation
Jeremias Maerki wrote: While we're at it: I think it's about one year since I got voted into the XML PMC. According to the following section of the XML project's mission statement: 5.4 Every 12 months, (or as required by the Board or PMC) each subproject of xml.apache.org will nominate 1-2 individuals to represent them on the PMC. To become a sub-project's representative on the PMC, an individual must be nominated by a contributor, unanimously approved by all PMC members, and approved by a two-thirds majority of the sub-project's active committers. In most cases, developers will have actively contributed to development for at least six months before being considered for membership on the PMC. ...it may be time to replace me as well. I have nothing against staying in this role for now (on the contrary) but I'd like to make the post available to Glen, if he desires it. I guess he's the only candidate matching the above criteria right now. Jeremias, I have no problem with your continuing. If we need a formal vote, Jeremias to remain as one of our PMC representatives: +1 Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Interaction between force-page-count and initial-page-number
Chris, Comments below. Chris Bowditch wrote: Peter B. West wrote: snip/ The Rec says of force-page-number:auto, 'If there is no next page-sequence or if the value of its initial-page-number is auto do not force any page.' Should that read, '...the value of its initial-page-number is auto, auto-even or auto-odd...'? If not, some questions of behaviour arise. Hi Peter - I dont think the spec needs to say auto-even or auto-odd here. Unless I'm missing something it seems clear to me that if initial-page-number=auto-odd and the force-page-number=auto on the previous page-sequence then a page must be forced when the first page sequence ends on an odd page. My point is that the spec is *not* clear on this. 1st p-s: What's your 1st number (my last is 11)? The 2nd calculates that it's first number must be 13, based on initial-page-number:auto-odd. 2nd p-s: 13 The 1st p-s now forces a blank page, numbered 12. If it were to query again, based on the new last page number, the dialogue would go I dont see why it needs to re-query just because the last page number changed. After all the last page number changed as a result of communication between ps1 and ps2, so why go round again? My purpose in setting this scenario out is to demonstrate that, in these circumstances, a requery is not necessary. In general, though, if you have a mutual dependency, and the conditions on one side of the dependency change, you're up for another round. In the circumstances outlined, the analysis indicates that no recursion is necessary. However, there is nothing in the spec to indicate that a page sequence with force-page-number:auto should include its current last generated number in a query. It simply indicates that such a page-sequence should find out from the following page sequence whether its first number is odd, even or auto, in order to determine its own last page number. Unfortunately, the following page sequence may not be able to answer that question without first finding out what the last page number of the preceding page-sequence is. The scenario I outlined goes beyond what the spec states in order to resolve the deadlock. If this process is intended by the editors, they need to spell it out. 1st p-s: 1st number (12)? 2nd p-s: 13 and the extra dialogue would be unnecessary. Is this the intention? I agree this extra dialog is unnecessary but I couldnt tell from the quotes you made why you think the spec implies that it is necessary. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: PMC representation change, still ot ack'ed
Jeremias Maerki wrote: I've just noticed that Joerg still hasn't been formally voted in in the XML PMC as a replacement for Peter. Since this was more than 2 months ago I wanted to check if this is still ok. I'll start the vote in the XML PMC on Wednesday if there are no objections until then. Joerg, In the meantime, as a vote is pending on the in principle acceptance of the federation proposal, if you let me know your vote on this I will forward it by proxy to the PMC. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Interaction between force-page-count and initial-page-number
The editors, I am seeking clarification of the relationship between the force-page-number and initial-page-number properties in certain circumstances: specifically, when the value of force-page-number is auto and the value of initial-page-number on a following page-sequence is either auto-even or auto-odd. Apart from the descriptions of the properties, I found no other discussion about the interaction of these properties. The Rec says of force-page-number:auto, 'If there is no next page-sequence or if the value of its initial-page-number is auto do not force any page.' Should that read, '...the value of its initial-page-number is auto, auto-even or auto-odd...'? If not, some questions of behaviour arise. Say, for example, the last generated page of a force-page-number:auto page-sequence has an odd number, and the following page-sequence has an initial-page-number value of auto-odd. The page-sequence queries the following page-sequence for first first page number. The second page-sequence, in turn, queries the first page sequence for its last page number. Who goes first? Because the 1st page sequence is the only source of information on actual generated page numbers, the following scenario seems reasonable. The 1st sequence queries the 2nd, passing its current generated last page number. The 2nd then uses this number to generate a response. Let's say the generated last number is 11. 1st p-s: What's your 1st number (my last is 11)? The 2nd calculates that it's first number must be 13, based on initial-page-number:auto-odd. 2nd p-s: 13 The 1st p-s now forces a blank page, numbered 12. If it were to query again, based on the new last page number, the dialogue would go 1st p-s: 1st number (12)? 2nd p-s: 13 and the extra dialogue would be unnecessary. Is this the intention? This approach avoids holes in the page numbering, but I note that the combination of force-page-count:odd and a following initial-page-number:auto-odd will force a such a hole. Whatever the case, it would be worthwhile adding a clarification to the Rec. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: FOP components
J.Pietschmann wrote: ... - avalon and logging for the base library. ... BTW 1. I'd like to get rid of the servlet.jar in our CVS. 2. If we standardize on JDK 1.4 as base (as it currently is), we could drop the Xerces, Xalan and xml-api jars as well. Our Jars seem to be somewhat outdated anyway. If we go to 1.4, should we also use 1.4 logging (java.util.logging) and possibly also the preferences API (java.util.prefs) for configuration/user agent/user prefs? I don't know Avalon, so I don't know what other facilities from there we are using or considering using. If we are involved in such considerations, we need to decide how we propose to support our 1.3 user base. The most recent discussions showed that a number of users face steep costs to upgrade to 1.4. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: FOP components
Peter B. West wrote: J.Pietschmann wrote: ... - avalon and logging for the base library. ... BTW 1. I'd like to get rid of the servlet.jar in our CVS. 2. If we standardize on JDK 1.4 as base (as it currently is), we could drop the Xerces, Xalan and xml-api jars as well. Our Jars seem to be somewhat outdated anyway. If we go to 1.4, should we also use 1.4 logging (java.util.logging) and possibly also the preferences API (java.util.prefs) for configuration/user agent/user prefs? I don't know Avalon, so I don't know what other facilities from there we are using or considering using. framework.ValuedEnum for one. That will have to wait until Java 1.5. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Just a small question...
Glen Mazza wrote: [Pardon me, Peter, for more shooting from the hip...] Don't mention it, Glen (whose contributions we all value highly.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Just a small question...
Andreas L. Delmelle wrote: Peter / Nikolai, I think I should be the one to apologize here, as Nikolai seems to have been offended by one of *my* unreflected shoots from the hip --hey, sometimes I'm in the mood for joking. If the joke comes across bad, I appreciate it when people tell me that it has, offering me an opportunity to clear things out. In this case, the only part saddening me is Nikolai deciding to unsubscribe as a consequence of one simple remark, that wasn't even serious (let alone 'reflected' criticism)... Andreas, Thanks for these comments. Glen has pointed out to me, off-list, the same thing. As I was the one who mentioned Glen by name (as neither Bertrand nor Jeremias did) I must acknowledge that leaving the 2nd-level quotes from you in my reply to Nikolai gave completely the wrong impression. I owe Glen an apology for shooting from the hip. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Peter) Re: Just a small question...
Glen Mazza wrote: Peter, Both of the remarks that Nikolai quoted [1] in leaving the list came from Andreas [2], not from me [3]. I was only stating the obvious in my warnings not to use their code. I don't appreciate you trying--for those who haven't been following the thread--to attribute Andreas' quotes to me. Glen Glen, That was a very misleading oversight on my part. I was aware that the quotes did not come from you, and should have removed them, but I forgot before I posted. I.e., I shot from the hip. My apologies. Nonetheless, and please don't take this amiss, I stand by the tenor of my comments. I think you need to consider the human effects of the way you express yourself. It's a chronic problem of email exchanges that they are read very differently from the way they are written. A forcefulness that can be quite inoffensive in face-to-face situations can easily generate very defensive responses in email. I suspect that was part of the problem in Andreas' response to you. I'm sure you know all this, and it applies to me as well. In retrospect, I should probably have expressed my opinions on this to you personally, while assuring Nikolai in public of my regret that he was most welcome on the list. Again, I shot from the hip, and I apologise for that. That said, I hope there may be some beneficial effects from stating those opinions in public, if someone else who reads them becomes less likely in future to take a comment of yours the wrong way. In that sense, my comments may take some pressure *off* you. I hope, at least, that some such beneficial outcome may arise from this. If there is anything else you would like me to say about this in public, please let me know. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Just a small question...
Nikolai Grigoriev wrote: I realize I was wrong when I answered to this forum - I could not expect my words to be interpreted this way. Please disregard my previous message; I also unsubscribe from the list, to make you feel sure I don't induce anyone into wrongdoing. RenderX (--still wondering which of the two is more true: either his employers have no idea what he's doing, or he doesn't care whether they know... or he is his own employer trying to lure me into doing something illegal --in which case he'll fail I _am_ in the position to decide myself how much technical information about RenderX XEP can be safely disclosed. But if you prefer to see any word that comes from RenderX as a fraud attempt, you're welcome. - hey, come to think of it, does RX need money or what? =D ) And they have the money - earned by writing software, not by cheating. Yours truly, Nikolai Grigoriev XEP Project Leader RenderX Nikolai, Please re-consider your decision. I, for one, am extremely pleased that developers on other XSL-FO projects, especially ones so successful as RenderX, are interested enough in FOP to monitor this list, and, even more, to respond here. If you have watched us for a while, you will realise that Glen tends to shoot from the hip, and expresses himself forcefully. (I have done the same on occasion.) More than one of the regulars here has been stung by Glen's comments, but we understand that that is Glen's manner. We value his contributions greatly, and shrug off the more over-the-top expressions of opinion because we are used to the way he says things. I hope you can bring yourself to do the same. Glen raised issues which we in FOP must consider carefully. However, I enjoy the community of interest between us and commercial developers, and if you or, say, Tony Graham from Sun's xmlroff, wants to chime in to the discussions I welcome the input greatly. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Synchronization questions
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] I've been hacking the tree methods in Node recently ... Are you talking 'maintenance vs. HEAD' here? No. I realise the message was ambiguous. I was talking about versions of my general tree-handling classes - Node (primarily) and Tree. My first change was to synchronize the methods which had previously been synchronized on the Tree, but I realized that such synchronization of methods in inner classes probably only synchronized on the actual inner class instance, not on the containing class instance. Does anyone have any knowledge of this? Hmm... Difficult to tell from the docs I read, so far... I'd say: indeed, unless the code-block through which the inner class (synchronized) method is accessed is synchronized on the containing class instance, no? Then again, synchronizing only on the inner classes could turn out to offer more flexibility, as other operations on the containing class can still be carried out while the inner class is locked (provided, of course, that the 'other' operations do not need access to the inner class instance...) In this case they do need such access. The inner classes are iterators. It also occurred to me that optional synchronization might be a good idea, allowing a common synchronization object to be passed to the Node constructor. An alternative was to allow optional synchronization, but to synchronize on the affected Node object. On the construction of any particular Node, a boolean can be passed indicating the need for synchronization. The other solution for the above stated issue: remove the synchronization from the inner class methods, and synchronize their bodies on the containing class instance. (Again: IIC you'd only need this if you really *need* to synchronize on the outer class... if you don't, I guess the approach you're taking now is more flexible and less likely to lead to deadlocks.) I was worried about increasing the probability of deadlock by having many more locks held concurrently. Without having thought about it a great deal, it seems to me that it is easier to appreciate and avoid potential deadlocks when synchronization is more global, as with the synchronization on the containing Tree object. snip / Does anyone have experience with such issues? No real experience, but thinking about 'optional synchronization' brings up all sorts of ideas, like: - a Lockable interface for Nodes - a SyncedNode extending Node implementing the Lockable interface - when you really only need a non- or partly synchronized Node use the main type; if you need a fully synchronized one, use the subtype (ratio of execution speeds from non-synced vs. synced is roughly 100 vs. 150, so it would definitely be worth it to avoid synchronization altogether where it is not strictly necessary) This would be the clean way to express the current version of the code. However, I am still toying with the idea of allowing (sub)trees to synchronize on an object passed in as a parameter to the Node constructor. If the object reference is null, synchronization is turned off. In this scheme, I would allow subclasses (like Area) to switch synchronization on by setting the 'sync' object non-null, as, for example, when a locally constructed subtree was grafted onto the AreaTree. It also returns to the situation of a common synchronization object for each node in the (sub)tree. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Synchronization questions
Peter B. West wrote: This would be the clean way to express the current version of the code. However, I am still toying with the idea of allowing (sub)trees to synchronize on an object passed in as a parameter to the Node constructor. If the object reference is null, synchronization is turned off. In this scheme, I would allow subclasses (like Area) to switch synchronization on by setting the 'sync' object non-null, as, for example, when a locally constructed subtree was grafted onto the AreaTree. It also returns to the situation of a common synchronization object for each node in the (sub)tree. The notion of switching synchronization on and off is, unfortunately, brain-dead. If synchronization is to be changed, then the code which changes and reads the synchronization state must itself be synchronized. The conditional synchronization that I have now is only workable because the setting for any particular node is immutable. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.
Simon Pepping wrote: I have the following considerations: 1. The old situation has pure datatypes, which in theory may be reused in other situations. In practice, these datatypes are very much bound to properties, so that reuse is not realistic, and does not happen in FOP code. Combining the notions of datatype and property is more tuned to FOP's situation. Alt-design has completely separate properties and data-types. Instances of datatypes contain int references to the property on which they were defined. 2. Even in the old situation the separation between datatypes and properties is not complete. Compound datatypes contain properties. Alt-design has no compound properties. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Updating licenses
Jeremias Maerki wrote:
Very cool! I did the whole thing manually back when I exchanged the
illegal short licence with the long one.
But I noticed the following:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1
It looks like the {YEARS} marker seems not to have worked on some files
you checked in yesterday.
Ahem...
That's because I cut-and-pasted the 2.0 license file into the pattern
Eclipse uses when constructing a new class. I forgot to fix {YEARS}.
Those new files haven't been run through the perl filter. Thanks for
picking this up, Jeremias.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Synchronization questions
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] ... I was worried about increasing the probability of deadlock by having many more locks held concurrently. Without having thought about it a great deal, it seems to me that it is easier to appreciate and avoid potential deadlocks when synchronization is more global, as with the synchronization on the containing Tree object. Yes, I see what you mean... Well, as I indicated, there's absolutely no reason to trust me on this. Your view is probably more to the point here. The only thing I do know for sure is that many authors claim that most possible cases of deadlock can --and should preferrably be - identified in advance (i.e. before any code is ever written). The two most common cases of deadlock are AFAIK: 1. A thread that doesn't exit (cleanly), so never releases the lock (threads going into an infinite loop belong to this category) This is always going to be tricky. 2. Two threads 'waiting for each other': one holding the lock and waiting for a return value from the second, the other needing access to the locked object in order to return the desired value. See comments below. So it would come down to predicting in some way the risk of either of these two taking place. I guess that, when synchronization is more global, the first type would be easier to avoid. Mostly, it's also advised not to synchronize *every* method, actually leaving a backdoor opened to be able to cleanly open the lock from the inside (--but I'm guessing this is well-known fact to you). This would be an argument against all-too-eagerly-global synchronization IMHO. It's only necessary to synchronize the methods that read or modify the data that is in contention. I suspect that a lot of synchronized code is written by those who don't quite understand why, and who take the first approach that seems to work. I get the feeling that quick and easy approaches are frequently encouraged. (On top of that, but this may be a consequence of the limitation of my understanding of the FO process in its entirety, it seemed easier to me to avoid the first cases manually and the second by design, than doing it the other way around. I'm still not completely familiar with the 'borderline' cases, where an event downstream would influence upstream events in such a way that they might need access to a Node on which a lock is being held by another process...) Deadlock problems have to be considered carefully at the design stage. In my original considerations for the pipelined model of alt-design, I was happy to have blocking writes/reads on the buffers of the primary pipeline (parser-fo tree builder-area tree builder), but I thought there would be deadlock problems if the return message queues were blocking. (See figure 3 - incorrectly captioned Figure 2 - of http://xml.apache.org/fop/design/alt.design/xml-parsing.html). I believe that the less complicated the synchronization structure, the easier it will be to analyse the possibilities for deadlock, hence my interest in getting back to more global synchronization objects. snip / However, I am still toying with the idea of allowing (sub)trees to synchronize on an object passed in as a parameter to the Node constructor. If the object reference is null, synchronization is turned off. In this scheme, I would allow subclasses (like Area) to switch synchronization on by setting the 'sync' object non-null, as, for example, when a locally constructed subtree was grafted onto the AreaTree. It also returns to the situation of a common synchronization object for each node in the (sub)tree. [Your follow-up: ] The notion of switching synchronization on and off is, unfortunately, brain-dead. If synchronization is to be changed, then the code which changes and reads the synchronization state must itself be synchronized. The conditional synchronization that I have now is only workable because the setting for any particular node is immutable. And so if you need a non-synched version of the same Node, you would need to create a non-synched clone/copy (--preferrably disposable)? It seems to be the only way to do it. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Updating licenses
Fops,
I have committed the perl script bin/lic_to_2 in FOP_0-20-0_Alt-Design.
It's function is to substitute license 2.0 for 1.1.
It is called as
$ lic_to_2 --lic2 {file containing license 2.0 text} {file to modify}
The intended usage is something like:
$ find . -name '*java'|while read file;\
mv $file $file.orig;\
do lic_to_2 --lic2 {lic2 file} $file.orig $file;\
done
I have already committed java and plain text versions of 2.0 to the root
directory of FOP_0-20-0_Alt-Design. Note that these license files
contain a {YEARS} marker which is replaced from the actual years in the
source file copyright notice when the script is run.
When we get the OK, I'll use this to update the licenses in alt-design,
and, if that works, I can also do the maint and HEAD sources.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Updating licenses
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: When we get the OK, I'll use this to update the licenses in alt-design, and, if that works, I can also do the maint and HEAD sources. Sounds quite good. You've made *many* friends today... ;) But Glen, I have *so* many already. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Constants in Area
Fops, Is org.apache.fop.layout.AreaClass going to be integrated with then constants defined in ...area.Area? Note that Area also has its own writing mode constants, in addition to those in Constants. The spec allows 'lr', 'rl' and 'tb' as short forms of 'lr_tb', 'rl_tb' and 'tb_rl' respectively. Although other writing modes are discussed, only those above are yet sanctioned in the Recommendation. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: cvs commit: xml-fop/src/java/org/apache/fop/datastructs Tree.java
Jeremias Maerki wrote: Peter, I think it's a bit premature to apply the 2.0 licence already. The board has announced additional information on how the licence should be applied. This is not a veto, I just want to avoid you having to do the whole thing twice. Another thing: Please pay attention to the copyright years. You have to take them over from the old licence. Oops. Thanks Jeremias. There is information on the web site about how to use the license, but I daresay it will need to be refined. I happened to be in the middle of a number of changes, so I went with the new license. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Synchronization questions
I've been hacking the tree methods in Node recently, triggered by the need to construct multiple subtrees during area tree construction, cobbling them together as necessary. In the original version, I was able to synchronize on the Node's containing Tree instance, but that is no longer feasible, as Nodes may be free-floating. My first change was to synchronize the methods which had previously been synchronized on the Tree, but I realized that such synchronization of methods in inner classes probably only synchronized on the actual inner class instance, not on the containing class instance. Does anyone have any knowledge of this? It also occurred to me that optional synchronization might be a good idea, allowing a common synchronization object to be passed to the Node constructor. An alternative was to allow optional synchronization, but to synchronize on the affected Node object. On the construction of any particular Node, a boolean can be passed indicating the need for synchronization. To implement this, I use the Node or the containing Node (in the case of inner classes) as the synchronization object. So iteration operations on the Tree (like those of PreOrder or PrecedingSibling) and bulk operations (like copySubTree) end up synchronizing on each Node during the traversal. This has the advantage that operations which occur relative to any given Node (like those of PrecedingSibling) can occur in parallel with activities in other parts of the tree. The disadvantages include the large number of possible synchronizations, and an unknown incremental risk of deadlock. Does anyone have experience with such issues? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Unnesting properties and makers.
J.Pietschmann wrote: Glen Mazza wrote: Well, instanceof is slower I believe, but better self-commenting. Instanceof is exactly as fast as a simple function call after warm-up. That's very useful to know. instanceof has had a very bad press. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Unnesting properties and makers.
Finn Bock wrote: [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x false method call 581 true method call 581 false instanceof 160 true instanceof 170 [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x false method call 1272 true method call 2304 false instanceof 17945 true instanceof 912 [/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x false method call 2154 true method call 2754 false instanceof 590 true instanceof 651 These appear to be running on the same system. It's good news for instanceof, but what startles me is the performance of 1.2.2 relative to 1.4.2_02 (and, of course, 1.3.1_03. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Unnesting properties and makers.
J.Pietschmann wrote: Peter B. West wrote: With my naive understanding of parsing as a two-stage process (lexemes - higher level constructs) I have been curious about earlier comments of yours about multi-stage parsing. Can ANTLR do this sort of thing? I'm not quite sure whether you mean by parsing as a two-stage process the same as I do. In language specs, the formal description is usually divided into a grammar level representing a Chomsky level 2 context free grammar and a lexical level, described by simple regular expressions (Chomsy level 0 IIRC). This is done both for keeping the spec readable and for efficient implementation ... This is basically what I meant - I see (and have experienced in FOP) the difficulty of trying to parse multiple grammars out of a single stream of lexical objects. Given the amount of hacking I had to do to parse everything that could legally be thrown at me, I am very surprised that these are the only issues in HEAD parsing. Well, one of the problems with the FO spec is that section 5.9 defines a grammar for property expressions, but this doesn't give the whole picture for all XML attribute values in FO files. There are also (mostly) whitespace separated lists for shorthands, and the comma separated font family name list, where a) whitespace is allowed around the commas and b) quotes around the names may be omitted basically as long as there are no commas or whitespace in the name. The latter means there may be unquoted sequences of characters which has to be interpreted as a single token but are not NCNames. It also means the in the font shorthand there may be whitespace which is not a list element delimiter. I think this is valid: font=bold 12pt 'Times Roman' , serif and it should be parsed as font-weight=bold font-size=12pt font-family='Times Roman' , serif then the font family can be split. This is easy for humans but can be quite tricky to get right for computers, given that the shorthand list has a bunch of optional elements. Specifically font=bold small-caps italic 12pt/14pt 'Times Roman' , A+B,serif should be valid too. At least, the font family is the last entry. Note that suddenly a slash appears as delimiter between font size and line height... This usage, AFAICT, is the reason that division is specified by the token 'div'. All a matter of CSS compatibility. Another set of problems is token typing, the implicit type conversion and the very implicit type specification for the properties. While often harmless, it shows itself for the format property: the spec says the expected type is a string, which means it should be written as format='01'. Of course, people tend to write format=01. While the parsed number could be cast back into a string, unfortunately the leading zero is lost. The errata amended 5.9 specifically for this use case that in case of an error the original string representation of the property value expression should be used to recover. Which temps me to use initial-page-number=auto+1. This is one of the disgraces of the spec - this time for compatibility with XSLT usage. XSL-FO just cops it sweet whenever someone else's problem (SEP) extrudes into the XSL namespace. Another famous case is hyphenation-char=-, which is by no means a valid property expression. Additionally the restriction to a string of length 1 (a char) isn't spelled out explicitly anywhere. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Changing policy on minimum JDK requirements for HEAD
Glen Mazza wrote: Here's the team's comments so far on this topic: Chris: http://marc.theaimsgroup.com/?l=fop-devm=107330434824865w=2 Peter West: http://marc.theaimsgroup.com/?l=fop-devm=107334589414161w=2 Glen: http://marc.theaimsgroup.com/?l=fop-devm=107334968118783w=2 Web Maestro Clay and John Austin: http://marc.theaimsgroup.com/?l=fop-devm=107336350330714w=2 Chris 2: http://marc.theaimsgroup.com/?l=fop-devm=107338058309642w=2 Web Maestro Clay 2: http://marc.theaimsgroup.com/?l=fop-devm=107339978229070w=2 Joerg: http://marc.theaimsgroup.com/?l=fop-devm=107341756423664w=2 Peter West 2: http://marc.theaimsgroup.com/?l=fop-devm=107353819024636w=2 Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: There was a thread recently which brought up that FOP HEAD currently doesn't compile under JDK 1.3. IMO this is an important point and a change of policy needs a community decision (vote) and a susequent documentation update. Since we should respect our customers a new opinion poll before the vote would be appropriate. Does anyone know of a good and up-to-date list of platforms and the JDK versions they support? I haven't found one. Sun's isn't ready, yet: http://java.sun.com/j2se/1.4.2/ports.html Another point of interest is that 1.5 is available in beta releases. 1.5 contains changes to the language, the only ones since 1.1, IIUC. I suspect that any vendor who takes Java seriously will port 1.5 as a matter of urgency. IBM e.g., has 1.3 and 1.4 for AIX and z/OS (what level of 1.4 I am not sure.) Linux/390 also has 1.4. We're talking about a product (1.0) without a definite release date, but unlikely before late 2004. I hope to have a very limited functionality available in alt-design by mid-year. In any case, I expect that by the time anyone is using alt-design in anger, 1.4 will not be a problem. The 0.20 series is supported on 1.3, so an important question is: what is the expected timeframe for availability of 1.4 for those users who are currently restricted to 1.3? Vendors should be able to provide their users with some indication of this. We should at least ask the question in any survey of users. An ancillary question is: what is the user's expected timeframe for migration? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Unnesting properties and makers.
J.Pietschmann wrote:
...
Well, one of the problems with the FO spec is that section 5.9
defines a grammar for property expressions, but this doesn't
give the whole picture for all XML attribute values in FO files.
There are also (mostly) whitespace separated lists for shorthands,
and the comma separated font family name list, where
a) whitespace is allowed around the commas and
b) quotes around the names may be omitted basically as long
as there are no commas or whitespace in the name.
The latter means there may be unquoted sequences of characters
which has to be interpreted as a single token but are not NCNames.
It also means the in the font shorthand there may be whitespace
which is not a list element delimiter. I think this is valid:
font=bold 12pt 'Times Roman' , serif
and it should be parsed as
font-weight=bold
font-size=12pt
font-family='Times Roman' , serif
then the font family can be split. This is easy for humans but can
be quite tricky to get right for computers, given that the shorthand
list has a bunch of optional elements. Specifically
font=bold small-caps italic 12pt/14pt 'Times Roman' , A+B,serif
should be valid too. At least, the font family is the last entry.
Note that suddenly a slash appears as delimiter between font size
and line height...
...
Alt-design takes a two-stage approach to parsing. In the first stage
the basic datatypes are detected. Where there are nasty constructs hung
over from CSS, as in 'font', the elements are collected into
PropertyValueLists, in a manner dependent on whether the components were
space or comma separated. From the javadoc comment to the 'parse'
method in ...fo.expr.PropertyParser
* Parse the property expression described in the instance variables.
*
* pThe ttPropertyValue/tt returned by this function has the
* following characteristics:
* If the expression resolves to a single element that object is returned
* directly in an object which implements PropertyValue/tt.
*
* pIf the expression cannot be resolved into a single object, the set
* to which it resolves is returned in a ttPropertyValueList/tt object
* (which itself implements ttPropertyValue/tt).
*
* pThe ttPropertyValueList/tt contains objects whose corresponding
* elements in the original expression were separated by emcommas/em.
*
* pObjects whose corresponding elements in the original expression
* were separated by spaces are composed into a sublist contained in
* another ttPropertyValueList/tt. If all of the elements in the
* expression were separated by spaces, the returned
* ttPropertyValueList/tt will contain one element, a
* ttPropertyValueList/tt containing objects representing each of
* the space-separated elements in the original expression.
*
* pE.g., if a bfont-family/b property is assigned the string
* emPalatino, New Century Schoolbook, serif/em, the returned value
* will look like this:
* pre
* PropertyValueList(NCName('Palatino')
* PropertyValueList(NCName('New')
* NCName('Century')
* NCName('Schoolbook') )
* NCName('serif') )
* /pre
* pIf the property had been assigned the string
* emPalatino, New Century Schoolbook, serif/em, the returned value
* would look like this:
* pre
* PropertyValueList(NCName('Palatino')
* NCName('New Century Schoolbook')
* NCName('serif') )
* /pre
* pIf a bbackground-position/b property is assigned the string
* emtop center/em, the returned value will look like this:
* pre
* PropertyValueList(PropertyValueList(NCName('top')
* NCName('center') ) )
* /pre
In the second stage (refineParsing) the lists are analysed in their
context (e.g. 'font') and the appropriate final values are developed.
The maintenance branch tried to unify all cases into a single
framework, which quite predictably resulted in a complex and
somewhat messy code. It's also less efficient than it could be:
format=01 is (or would be) indeed parsed as expression, while
an optimized parser can take advantage of the lack of any string
operations and look for quoted strings and function calls only,
returning the trimmed XML attribute value otherwise.
This sounds promising.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Compiling HEAD
Is HEAD supposed to be compiling? I'm getting errors starting at datatypes/ColorType.java. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Alt-design: framework for marker handling
Recent commits to alt-design have laid the groundwork for handling of fo:marker within fo:static-content. ...xml.SyncedXmlEventsBuffer now extends ...datastructs.SyncedCircularBuffer and implements ...xml.XmlEventSource. A new class, ...xml.XmlEventsArrayBuffer, also implements XmlEventSource. ...xml.XmlEventReader, which has been extracted from ...xml.SyncedXmlEventsBuffer, requires an XmlEventSource argument to its constructor, and provides a general pull-parsing mechanism based (for now) on an XmlEventSource, and later, probably, an XmlEventSourceStack. ...fo.flow.FoMarker and ...fo.flow.FoStaticContent both use a new method in XmlEventReader to flush their contents into an XmlEventArrayBuffer, for later reading during the construction of static regions. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Unnesting properties and makers.
Finn Bock wrote: I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. [J.Pietschmann] I think you could leave the file there for now. Ok. It should be sufficient to inactivate the related task in the buildfile (for example putting it in an XML comment). Too late for that, but I'll reactive the lines as comments tomorrow. Does anyone know why we wrap the datatypes instances in a property instance? No. Actually we should strive to use a proper parse tree for property expressions: 1. Create a few classes for the symbols in the property expression grammar (section 5.9 of the spec). I think we need as terminals - AbsoluteNumeric - RelativeNumeric - Color (the #N thingy) - String (aka Literal) - NCName (everything else, basically, including enum tokens and inherit) and for the nonterminals - PropertyFunction - Some classes for the operators 2. Write a proper parser (maybe using ANTLR, at least for bootstrap) which produces a proper parse tree. With my naive understanding of parsing as a two-stage process (lexemes - higher level constructs) I have been curious about earlier comments of yours about multi-stage parsing. Can ANTLR do this sort of thing? 3. Add methods to the objects for resolving relative numeric values (percentages, em) and for evaluation. 4. Perhaps add constant folding to the parser. Interesting. What issues do we have in property parsing that is solved by this? I'm only aware of arithmetic on relative numerics which doesn't work. Given the amount of hacking I had to do to parse everything that could legally be thrown at me, I am very surprised that these are the only issues in HEAD parsing. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Iframes
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] I assume this problem is with the iframes? Well, not my eye-frames... but if that's what these charming windows on the sources are called, then, yes. Anyway, this could well be added as a feature to the other fop-dev pages, if you ask me. Andreas, Thanks for the vote of confidence. I agree with you entirely, which may not come as a surprise to you. I used XEmacs to generate the html, but there is a better way. When I was working on it, Nicola Ken Barozzi was trying to integrate the SourceForge Javasrc project into Alexandria, but it was stalled due to licensing issues. I think that has since been resolved, and Javasrc is available. There was some talk about providing it for the automatic generation of the codebase in html. The nice thing about Javasrc is that it provides targets for just about everything in the source files. Combining such a html codebase with documentation, such as is done in alt-design is a powerful way to document code. As long as the references into the code remain valid, the documentation is automatically updates with the latest version of the source. If the source changes too much, the links break, and Forrest output could be used to flag such breakages. Not having been there for a while, I'm not sure if there are new facilities in Forrest that mean I can re-organize the documentation. The other issues I had were, as you have noted, browser-related. I went for DOM support, but even so, I found that IE and Mozilla/Netscape differed in significant ways. I even found that the behaviour of Mozilla differed between linux and windows. Such issues should gradually clear up. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: @author tags in source files (Was re:cvs commit....)
Glen Mazza wrote: Indeed, last vote about 6-8 months ago was to deprecate the @author tags, and that rule is still on our web site. We'll need a revote to allow them. As a committer, I personally have never bothered with @author tags, but I do like how they show outside developer and corporate contributions to our project. The Batik team has some 1800 attributions of various developers, Xalan checks in with about 650. Cocoon seems to use them as well. (Those are the only projects I've checked, I don't know how Jakarta is.) After layout and properties are done--I would be thrilled if some companies, liking our product, decide to donate us specific renderers--maybe HP would have a team do a PCL renderer for us, IBM another. Or maybe a bright small company wants to advertise its skills. If they want to have their names on an @author tag, that's a very cheap price for us to pay. Before we put on a lawyer hat and declare that @author tags threaten to take precedence over the Apache license--let's take this issue to the ASF for guidance. (After all, they might have legal aspects, and they have drawbacks in that they can get messy if overused.) As far as I can tell from the other projects though, @author tags are still kosher. Dirk-Willem, does Apache have any position on @author tags or other author attributions in source files? See below for examples. Thanks, Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/org/apache/fop/render/awt/Attic/AWTRenderer.java?rev=1.45view=auto [2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/render/rtf/RTFHandler.java?rev=1.13view=auto [3] http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/parser/AWTPolylineProducer.java?rev=1.3view=auto [4] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/reading/ImageReader.java?rev=1.4view=auto --- J.Pietschmann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: removed former contributor section in favor of going back to giving credit within source files. Uh, oh. That's not supposed to be a change anybody can make on a whim. J.Pietschmann Again, I'm sorry I didn't contribute to this debate earlier. There is no conflict between the ownership of the copyright and the authorship. Last I heard, most of the copyright in the Beatles catalogue was owned by Michael Jackson. He gets the money, while Lennon and McCartney (and Harrison and Starr) get the credit. It seems to me that a major motivation for writing OSS is precisely the recognition. When alt-design is completed, I will probably have written the bulk of it, as well as designing it, and I have no intention of removing my @author tags. Why should they be removed in favour of a mailing-list address? In respect of multiple @author tags, Sun says only that they should be added in chronological order, with (it follows) the author of the class first. They add: 'In these days of the community process when development of new APIs is an open, joint effort, the JSR can be consider the author for new packages at the package level. For example, the new package java.nio has @author JSR-51 Expert Group at the package level. Then individual programmers can be assigned to @author at the class level.' I would expect that any significant addition (from a new, or completely rewritten method) or significant accumulation of minor fixes, rates a mention in the source, and on the web page. Apart from the warm inner glow, what other reward is there? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: cvs commit: xml-fop/src/documentation/content/xdocs team.xml
[EMAIL PROTECTED] wrote: gmazza 2004/01/19 15:56:50 Modified:src/documentation/content/xdocs team.xml Log: Updated team page--moved Finn, Andreas, Chris and Peter to active status; set Victor and Keiron to inactive status, removed former contributor section in favor of going back to giving credit within source files. I'm sorry that I didn't contribute to the discussion on this, but I think that Mark Lillywhite deserves an honourable mention on the web site. He saved Fop for many users by introducing page-sequence formatting. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Comments on new property maker implementation
Finn Bock wrote:
I probably need an example of what you thinking are here. Right now in
HEAD all the color keywords are stored in a HashMap created in
GenericColor so the keywords initialization is already done. Putting the
keywords in static array would require us to somehow search the array
and I don't see how that will be much faster.
You should perhaps also be aware that the values in a static array gets
assigned to the array one element at a time. So
static int[] a = { 101,102,103,104,105,106,107,108 };
becomes in bytecodes:
Method static {}
0 bipush 8
2 newarray int
4 dup
5 iconst_0
6 bipush 101
8 iastore
9 dup
10 iconst_1
11 bipush 102
13 iastore
14 dup
15 iconst_2
16 bipush 103
18 iastore
...
and so on for each index. (In case you don't know bytecode by heart,
iconst and bipush both push a constant on the stack and iastore pops 3
items from the stack; an index, a value and an array and assign the
value to the index in the array).
Finn,
I can't imagine there is anyone here who doesn't know bytecode by heart.
(Except maybe me.)
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: HashMap
Andreas L. Delmelle wrote: Hiya Peter, ... Seriously? Not at all! (BTW: Shouts for your alt-design pages. Very comfortable --although IE seems to have a little trouble with the JavaScript adding a horizontal scrollbar instead of a vertical one; with other browsers no prob whatsoever.) Andreas, I assume this problem is with the iframes? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
XSL 1.1 WD fo:retrieve-table-marker
Paul, Excuse me for firing off a comment from the hip, but I have just looked at the putative fo:retrieve-table-marker FO. Prima facie, it looks to behave like fo:retrieve-marker, except with respect to table headers and footers. The difference that immediately occurs to me is that fo:retrieve-marker can logically occurs after the layout of region-body, and, because the dimensions of those regions which are the targets of static-content are size-constrained by the applied master-page. This simplifies the resolution of the marker. With fo:retrieve-table-marker, the possibility seems to exist that the formatting of a table-marker may change the region-body layout, and the page boundaries, to the extent that the source fo:marker may change. We have then another one of those awkward catch-22s of page layout. I may have missed something in my brief scan of the text, and I would appreciate any light on the subject. If my knee-jerk response is correct, fo:retrieve-table-marker can just be added to the list of layout nasties. It is hardly a show-stopper, given the similar unavoidable problems that already exist. Another thing that occurs to me as a result of these considerations is that the editors might comment (even non-normatively) on such issues, and possible strategies for resolving them. Your own non-normative feedback would be much appreciated. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: XSL 1.1 WD fo:retrieve-table-marker
Peter B. West wrote: Paul, ... The difference that immediately occurs to me is that fo:retrieve-marker can logically occurs after the layout of region-body, and, because the dimensions of those regions which are the targets of static-content are size-constrained by the applied master-page. This simplifies the resolution of the marker. I'll say that again. The difference that immediately occurs to me is that fo:retrieve-marker can logically occur after the layout of region-body, and, because the dimensions of the target regions of static-content are size-constrained by the applied page-master, the layout of those markers can have no impact on the layout of region-body. This simplifies the resolution of the fo:retrieve-markers. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: HashMap
Andreas L. Delmelle wrote: Depends on what portions you're used to, not? ;) I'd never trust public media though, when it comes to providing us with an accurate estimate of this figure... many would have us believe that the DRD is 0.0 --sigh. When is anyone going to realize the trouble is (practically) never the *buyers/consumers*, even less so the *makers/producers*. Problem is always, as with most goods, the *sellers/distributors* :) An _honest_ salesman? Honestly... Andreas, I hope you're not casting aspersions on my producer/consumer buffers? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [Bug 25480] - Experimental performance improvements.
Finn Bock wrote: [Peter B. West] Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties. When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values If I understand the Alt-design code correctly, the function calls, like from-parent(), are resolved but percentage are not resolved at this point, but still saved as an IndirectValue, right? The percentage will be resolved at a later stage? Basically, yes. There are complications with from-parent() and from-nearest-specified-value() when used with shorthands. These have lead to the creation of the FromParent and FromNearestSpecified pseudo-types. (not properties - one of the differences with HEAD) I think you have mentioned this before, but is it such a big difference? HEAD wraps its datavalues in a very thin Property wrapper, but otherwise there is a one-to-one binding between a HEAD Property and its value. I freely admit that when I started working with properties, I had only the fuzziest notion of the way they were processed in the original code. I'm not a lot better informed now. However, the idea of expressing properties in terms of data values still seems to me to be strange. Even though individual properties may *eventually* resolve to a particular basic type, the road there can be very complicated. It seemed to me that I should be able to process property values into a range of possible data types (e.g. enumerations and lengths), postponing the resolution into a particular, say, length, as long as possible. The other issue was that some types (enumerations, strings) resolve eventually into very different types depending on the property on which they are expressed. The Rec. (and consequently the parser) allow a multiplicity of different data types in the expressions on many properties. It just seemed cleaner to me to separate properties (which have certain static characteristics) out from data types. That way, I have the option of resolving different datatypes into their final datatype downstream of the parsing and FO tree building. I am open to enlightenment on this. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
HashMap
A friend was watching over my shoulder as I was responding to an earlier message on fop-dev. HashMaps... I won't say what image that conjures up for me. Well? A map of where you have the stash. I never thought of it that way. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [Bug 25480] - Experimental performance improvements.
Andreas L. Delmelle wrote: Sorry for the long post... Just trying to put a few ideas together. Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties. When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values (not properties - one of the differences with HEAD) and then thrown away. Yum... so a Collection of Objects is traded for a handful of --what? (Would this be the propertyValue singletons you mention?) If I mentioned PropertyValue singletons, it was a slip of the fingers. I maintain Property singletons, which are exist solely to provide access to certain static information about individual properties. What happens with 'unresolvable' Props at that point (for the cases you mention below)? See the package org.apache.fop.datatypes.indirect, especially IndirectValue, which the others extend. IndirectValue itself extends AbstractPropertyValue. Unresolved values take their place alongside the resolved properties. Do they get thrown away, or placed in a sort of Property stack for later accessing? If so, how exactly do you indicate in the FObj (or FONode) that the property in question still has to be resolved? So that, when Layout asks for this property, it is signaled that some computations still need to be made? (Pardon me if these questions mean I haven't read your docs thoroughly enough; I did read some of them, but it seems I still miss a bit of technical background to fully understand it.) The docs are far from adequate. This approach has to be modified in two environments - fo:static-content and fo:marker. In the case of fo:marker, the inherited environment is not known at parse time, and in the case of static-content, the appropriate fo:retrieve-marker subtrees are not know until the region-body area tree is constructed. Yes... cases I was overlooking --not so plain inheritance as the FObj's for static-content appear only once or twice every page-sequence, but their inherited properties and values vary, depending on the further processing of the tree. Still, I'm wondering whether you really need to re-parse them (as you indicated)... Couldn't you just, say, keep the Property alive and alter its value when needed? (If this would save you any re-initializing, I mean) The re-parsing idea seems very interesting to be able to say after a threesome of pages have been processed: collapse the branches of the FOTree that have already been layed out to the level below the current fo:flow (or fo:block; in any case some logical point of reference). If downstream, it turns out that their layout needs to be modified again (what are the odds? any way of predicting this?), one could trigger a re-parse from the subtree in question onwards. (This would, I think, save us some memory) The re-parse may not be strictly necessary, but it is a workable first cut. Generally, static-content and markers will not be large subtrees, so re-parsing them ought not to have a major impact. This can be experimented with once the layout is working. The beauty of the approach is that it simplifies the logic, without (I hope) costing too much in performance. In terms of the re-layout, re-parsing is not required (Re, re, re your boat...) IndirectValues will need to be re-evaluated in the new context, but the process of re-layout is not markedly different from the normal layout process. Any particular lineage descendant from an fo:flow must be able to adapt to a new environment. Because the page is a logical unit different from the flow, some line of descent from the fo:flow will be unresolved when any particular page, which is being laid out from that flow, fills up. The incomplete lineage must somehow be associated with the new page, whose region-body dimensions may be different. The layout must then proceed from the point at which the previous page filled. There are similarities here with backtracking. Backtracking layout involves backtracking to a particular lineage in a particular state (even it that is the beginning of an fo:flow.) Perhaps the same approach can be taken WRT tables: collapse all finished rows, so their cells are released. When their layed-out state turns out to be insufficient, start processing again from the row in question onwards, *with* the knowledge of what lies ahead this time... Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [Bug 25480] - Experimental performance improvements.
Finn Bock wrote: [Glen] One thing I'm missing here, for Finn's design below: values[0] = null // always null. values[1] = reference to a 'foo' Property instance values[2] = reference to a 'baz' Property instance Can't we just have, say, values[1] refer to the parent's Property instance in cases where inheritance is applicable? I.e., for all those references to the 'foo' property instance for the children of an FO where that value would be inherited, we don't have to create a new Property instance, just a reference to the inherited instance. Right, that is also the way I see it. But if the problem is the *recursion* necessary to determine the property instance to inherit--here, not the memory problem, but processing speed--I'm thinking of a PropertyWindow instance as follows: A PropertyWindow would be used temporarily during FObj property initialization to hold references to all the property instances that would be relevant for that FObj should a property not be explicitly defined. So, to populate the property instances for a particular FObj, i.e., the values array: Pardon me for repeating what might be obvious, but I'll like to take a look at what information we want to store at each FObj. I can come up with 3 different strategies: 1) Only store the specified properties. That is what HEAD does now. 2) Put the relevant properties in a fast Property[] array and the remaining specified properties in a HashMap. For fo:root the result would be an array of size 1 for the 'media-usage' property. 3) Expect to store every valid property. For fo:root that would mean allocating an array large enough to store every defined property. This is what my patch does, and the values array works as the PropertyWindow. As I understand your PropertyWindow proposal, it would allow us to implement no. 2) above. I'll try to come up with some numbers to see how much memory that would use/save compared to 1) and 3). Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties. When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values (not properties - one of the differences with HEAD) and then thrown away. This approach has to be modified in two environments - fo:static-content and fo:marker. In the case of fo:marker, the inherited environment is not known at parse time, and in the case of static-content, the appropriate fo:retrieve-marker subtrees are not know until the region-body area tree is constructed. In general, the impact on storage of maintaining full details for fo:static-content and fo:marker will not be huge, even if these are parsed as encountered. However, the plan for alt-design is 1) not the parse an fo:marker subtree unless and until it is required, and 2) to re-parse fo:static-content for each page after the region-body area tree has been constructed. (I'm working on these modifications now.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Remember to update the copyright year
Jeremias Maerki wrote: Fellow committers We've got a new year. Please remember to update the copyright year on every file you change. Thanks for the reminder, Jeremias. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fix for handling column-spanning ( and a few column props )
--- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:25 --- OK, I think I found the solution to the first case (as already mentioned to Finn off-list): Re: off-list discussions. My own view is that off-list discussion should be restricted to personal or inter-personal matters. I have only posted off-list on a few occasions, and I think three times before doing so. If the question is at all technical, post to the list. This is how all of the developers keep abreast of the development of ideas in design and implementation. If we don't follow this policy, we risk fostering cliques, and anyone who tries to follow the development of an idea in the archive will be at a loss. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fix for handling column-spanning ( and a few column props )
Peter B. West wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:25 --- OK, I think I found the solution to the first case (as already mentioned to Finn off-list): Re: off-list discussions. My own view is that off-list discussion should be restricted to personal or inter-personal matters. I have only posted off-list on a few occasions, and I think three times before doing so. If the question is at all technical, post to the list. This is how all of the developers keep abreast of the development of ideas in design and implementation. If we don't follow this policy, we risk fostering cliques, and anyone who tries to follow the development of an idea in the archive will be at a loss. P.S. Lest anyone think this is directed at him, I confess to being a recent culprit in my discussions with John about patches to alt.design. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Remember to update the copyright year
Andreas L. Delmelle wrote: If nobody objects, this seems like an ideal pesky task for a freshman... I mean: would it help if I (or Chris, or Clay ;P ) just checked out all of HEAD (to begin with), run a S R script on all the java and generator sources to update the year and enter it as a patch in Bugzilla or something? Unless the intention is to only update files that are actually changed. In that case I haven't posted anything. I'm not sure about this, but I would have thought we only change the notice in files that are modified. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fix for handling column-spanning ( and a few column props )
Andreas L. Delmelle wrote:
Morning Peter! ('t is morning over there not? :) )
Completely agree with you on this. Was a mere exception, not being
subscribed to fop-dev at work. Just having a bit of spare time over there,
decided to have a look at Finn's test cases and in all my excitement I just
wanted to post it to _someone_.
Just so you know...
Enjoy your w.e.!
Afternoon. Working this w.e.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Dropping support for 1.3 (was Re: PropertySets)
J.Pietschmann wrote: Chris Bowditch wrote: The main thing to bear in mind is that a few platforms dont support the later versions of Java. This will mean excluding those users from deploying FOP on their production servers and mainframes. Well. Java 1.4 has some added goodies, in particular nestable exceptions which will make problem tracking much easier, the BIDI support, other AWT fixes and extensions and JCE by default (people will still have to get a RC4 provider though :-/). And 1.4 has java.util.logging and java.util.prefs. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Attribute processing order
Simon Pepping wrote: On Thu, Jan 01, 2004 at 12:20:09AM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-01-01 00:20 --- Alt-Design addresses this problem by the simple expedient of processing properties in integer property number order. In main that is not possible. When a compound attribute is encountered, a compound property is made in which the components are set to default values. Then the specified component is set to the specified value. After this it cannot be told which components were specified by the user and which were defaulted by the program. Therefore, before dealing with the compound attribute, the base attribute should be processed if that is specified as well. This would be different if the compound property would not be filled with default components, but with null components. That's why a flat property space is not only feasible, but desirable. Compound properties are an unnecessary complication. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: PropertySets
Chris Bowditch wrote: Glen, Ive just noticed that the PropertySets class uses methods on java.util.bitset that only exist since JDK 1.4. Namely: cardinality nextBitSet So you can no longer build with 1.3 Chris Chris, Thanks for pointing this out. I had not noticed when I was using the functionality (and very useful functionality it is.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Immediate plans for alt.design
Fopsters, Having woken from my torpor, I am planning to re-activate alt-design development. My immediate plans include: Standardizing the name of alt.design. Marker processing . Generalise SyncedFoXmlEventsBuffer to handle events from any supported namespace . Generalise buffer definitions to support circular and fixed-length XML event buffers . Generalise SyncedFoXmlEventsBuffer to read from any buffer type supporting the buffer Interface . Modify SyncedFoXmlEventsBuffer to read from a stack of buffer Interfaces, popping exhausted event buffers as required . Modify initial marker processing to read fo:marker subtree events into individual marker event buffers . Modify fo:static-content handling to (initially) read static-content XML events into per-page static-content buffers The marker handling will be more or less in accordance with the notes posted here: http://marc.theaimsgroup.com/?l=fop-devm=105455437221298w=4 Percentage expressions . Add RPN expressions as a PropertyValue type, along the lines proposed here: http://marc.theaimsgroup.com/?l=fop-devm=105391772500443w=4 Area construction . Make the first attempts at area resolution on a per-page basis, providing immediate area context for FOs for resolution of percentage based expressions in most cases. Corresponding properties . Add corresponding property handling. That should keep me (and anyone else who wants to become involved) busy for a while. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Changes to Property sub-classes
I have just made a series of changes to property processing in alt.design, intended to 1) make the process look more familiar to Java familiars, and 2) speed things up a bit. property = (Property)(pclass.newInstance()); properties[propindex] = property; // Set inheritance value if ((inherited[propindex] = pclass.getField(inherited).getInt(null)) != Property.NO) inheritedprops.set(propindex); // Set datatypes datatypes[propindex] = pclass.getField(dataTypes).getInt(null); // Set initialValueTypes initialValueTypes[propindex] = pclass.getField(initialValueType).getInt(null); traitMappings[propindex] = pclass.getField(traitMapping).getInt(null); Basically, the foregoing code, which used reflection to obtain public static fixed int vales from the Property sub-classes, has been replaced by // Instantiate the class property = (Property)(pclass.newInstance()); properties[propindex] = property; // Set inheritance value if ((inherited[propindex] = property.getInherited()) != Property.NO) inheritedprops.set(propindex); // Set datatypes datatypes[propindex] = property.getDataTypes(); // Set initialValueTypes initialValueTypes[propindex] = property.getInitialValueType(); traitMappings[propindex] = property.getTraitMapping(); relying on the newly added getters in Property and its subclasses. Because of all the bad press for reflection, I expected to see an improvement of the speed of processing. I was disappointed in this. Unfortunately, I have only a poorly endowed laptop at the moment, so it is difficult to get sound measurements while Eclipse and Mozilla are running, but the results were inconclusive, sometimes recording faster times for the original code, sometimes for the new version. In any case, the approach I originally took incurs no performance penalty under 1.4, and may even be slightly faster. However, given the disturbance which seems to overcome Java programmers when face by code which is not strictly OO, I have checked in the new version. It may make cross-fertilization with Finn's work easier. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Unnecessary import of Constants
Eclipse is still complaining to me 271 times of the unnecessary import of fo.Constants in the files of build/gensrc/org/apache/fop/fo/properties. It also whinges about an unnecessary semi-colon in TextAlignLastMaker.java from the same directory. It's actually an empty else condition. Is anyone inclined to fix the generator, or is all of this going into CVS or is it all being superseded by Finn's new approach? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: cvs commit: xml-fop/src/java/org/apache/fop/svg AbstractFOPTranscoder.java
This one had a suspiciously large number of unused imports. I couldn't see where they might be required, but someone else may have a more accurate idea of why they must be reinstated. Peter [EMAIL PROTECTED] wrote: pbwest 2004/01/02 19:23:51 Modified:src/java/org/apache/fop/svg AbstractFOPTranscoder.java Log: Remove unused imports to quieten Eclipse. Revision ChangesPath 1.4 +0 -6 xml-fop/src/java/org/apache/fop/svg/AbstractFOPTranscoder.java Index: AbstractFOPTranscoder.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/AbstractFOPTranscoder.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- AbstractFOPTranscoder.java 7 Nov 2003 21:54:32 - 1.3 +++ AbstractFOPTranscoder.java 3 Jan 2004 03:23:51 - 1.4 @@ -50,17 +50,12 @@ */ package org.apache.fop.svg; -import java.awt.Dimension; -import java.awt.geom.AffineTransform; -import java.awt.geom.Dimension2D; - import org.xml.sax.EntityResolver; import org.apache.avalon.framework.logger.ConsoleLogger; import org.apache.avalon.framework.logger.LogEnabled; import org.apache.avalon.framework.logger.Logger; import org.apache.batik.bridge.UserAgent; -import org.apache.batik.bridge.UserAgentAdapter; import org.apache.batik.dom.svg.SVGDOMImplementation; import org.apache.batik.dom.util.DocumentFactory; import org.apache.batik.transcoder.ErrorHandler; @@ -70,7 +65,6 @@ import org.apache.batik.transcoder.image.ImageTranscoder; import org.apache.batik.transcoder.keys.BooleanKey; import org.apache.batik.util.SVGConstants; -import org.apache.batik.util.XMLResourceDescriptor; import org.w3c.dom.DOMImplementation; /** -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Recent tidying of alt.design
Recent minor changes to alt.design triggered by comments from John Austin. In particular, John drew my attention to HashMap initialization. I naively assumed that providing an initial size to a HashMap would take account of the default load factor. Re-reading the documentation, I came to the conclusion (with John) that this was not the case. That is, creating a hash with hm = new HashMap(20); then adding 20 items to it, will force a rehash after 75% of the items have been added. Silly as it seems, that appears to be the way of it. Does anyone else have any experience of this? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: AW: help with upload the ssh key
Glen Mazza wrote: Thanks, Peter, that helped a lot--I downloaded puttygen and am working with it now. Three more questions if anyone can help: 1) I guess we're to use SSH2 and not SSH1, but does it matter whether we use DSA or RSA? Is one much slower than the other? I'll use DSA--it apparently works for you and Joerg. I don't know whether DSA or RSA is preferable, but SSH2 is definitely preferable to SSH1. 2) Also, you placed your public key in authorized_keys, not authorized_keys2 like Joerg has. (Both of you are using DSA apparently.) Also, PuttyGen seems to indicate that authorized_keys is only for SSH1/RSA and authorized_keys2 is for SSH2 (RSA or DSA version). Does this matter--shouldn't you have yours in authorized_keys2? When I set mine up (at the same time as Joerg) I recall having to use authorized_keys2 (and biting off chunks of my keyboard discovering that.) Since then, I think the situation has changed and the use of authorized_keys2 is deprecated (or so I was told recently on a RH9 list.) 3) To use Putty on my work computer (besides my one at home--where I've just created the key), should I create another private/public key pair, and append the public key to my authorized_keys/keys2 file, or just transfer my private key to the second computer (via floppy disk, etc.)--what is the more usual/accepted practice? When I was working with Putty to a Linux server, I found that it was easiest to generate the keys on the linux machine, move the private key to Windows, and use the import facility in Putty. Work environments tend to be a bit insecure, especially it you are using pageant (or ssh-agent on linux) to save having to key in the passphrase. If you are accessing the repository from both your work and home machines though, it doesn't seem to make much sense to have different keys. I used the key i have already used for accessing jfor's cvs repository at sourceforge. I created the key about 6 month ago with puttygen. I ran it on my local computer (win2000 prof.). But you cannot use the files which puttygen creates when you click on one of the save buttons. Instead i copy-and-pasted the content of the Public key for pasting into OpenSSH authorized_keys2 file-textbox. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [VOTE] Finn Bock for Committer
Oleg Tkachenko wrote: J.Pietschmann wrote: Glen Mazza wrote: Therefore, I'm happy to nominate Finn Bock for committer +1 +1 +1 -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Merry Christmas/Frohe Weihnachten!
Glen Mazza wrote: Yes, thankfully Bertrand came to the rescue for us here! +1 Merry Christmas and Happy New Year everyone! +1 --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Happy Holidays ( to everyone who cares ) ! Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
usage-context-of-suppress-at-line-break
Regarding the recent discussion of space and line break characteristics, I recall that Karen was engaged in a very protracted discussion with the editors on aspects of these questions. At one stage they specified a new property usage-context-of-suppress-at-line-break to resolve issues Karen had raised. To the best of my recollection, this decision was later rescinded, and a clarification added to the pre-existing properties. I have looked for information about this at the W3C, but so far have only recovered the note in http://www.w3.org/2001/10/REC-XSL-20011015-errata What would be more useful is to trace the complete thread of the discussion, including the putative rescinding of this property. If Karen is listening, she may be able to offer some guidance. I remembered this because I added usage-context-of-suppress-at-line-break to PropNames.java, and noted that I would have to remove it after I read the update from the editors. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
