Re: Integration of TIFFRenderer in FOP
Glen Mazza wrote: Yeah, Peter makes me want to do that sometimes myself... ;) Glen Glen, It's not difficult. I can give you some tips off-line if you like. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Integration of TIFFRenderer in FOP
Jeremias Maerki wrote: Relationship to which PDF renderer? The one that directly creates PDF (PDFRenderer) or the one that creates PDF through JPS (normal PrintRenderer as defined in the Wiki painting to a Graphics2D instance provided by JPS) using a StreamPrintService? That's the two choices. Obviously, you will be taking the latter approach. If you wait a bit (until the common components area is set up) you'll have a neatly separated package to create PDF using JPS because I'll be publishing my proof-of-concept JPS StreamPrintService which you can build on. Hmm, this gives me another thing to talk about over in XML Graphics General. On 09.03.2005 00:53:16 Peter B. West wrote: This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Jeremias, That will be extremely useful. However, I was trying to clarify the situation of PDFRenderer. The impression I got from Renaud's comment was that the Java2DRenderer was to be the basis of all renderers. Hence my interest. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Good job! / Re: Integration of TIFFRenderer in FOP
Renaud Richardet wrote: Peter, let me answer you last mail [1] here: You are right that the wiki is still vague about the detailled implementation of the different renderers. Actually, I haven't started to think about it until today. I will put my ideas tomorrow on the wiki. I would be happy if you could put your inputs there, too. Renaud, I don't have particular input. I haven't given the rendering any detailed thought at all, apart from the perception fostered by the presence of PDFGraphics2D, PDFGraphicsConfiguration, PDFGraphicsDevice and similar classes in other contexts, that a mapping of the Area tree to Java Graphics2D output could be translated very directly into PDF (and other formats). If that necessarily involves the JPS, so be it. In order to flesh these notions out, I will be taking maximum advantage of the expertise of others, including yourself. In the meantime, I continue to work on the generation of the Area tree. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Integration of TIFFRenderer in FOP
Renaud Richardet wrote: Peter, Then my comment gave you a wrong impression: the Java2DRenderer is the (abstract) base for all renderers that use the Java2D API for rendering. The reference renderer is still the PDFRenderer, which inherits from AbstractRenderer directly. Renaud Renaud, Understood. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Integration of TIFFRenderer in FOP
Renaud Richardet wrote: Oleg, I'm currently working on the AWTRenderer. The basic idea is to create a Java2DRenderer which provides the (abstract) technical foundation. Other renderers can subclass Java2DRenderer and provide the concrete output paths [1]. I think it would be a good idea to integrate your TIFFRenderer, as you propose in [2]. Would you like to integrate it yourself? Otherwise I would like to do it. Regards, Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D [2] http://www.tkachenko.com/fop/fop.html Renaud, This approach is obviously of interest to me, and I will follow developments closely. The wiki page is very general. If the Java2DRenderer is to be the (abstract) technical foundation, what will the relationship to the concrete PDF renderer be? The wiki is vague on this point. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Skype-conference on page-breaking?
Jeremias Maerki wrote: I don't know why this is important to you Just curious. but it's two to three months. Ouch. Good luck. You might want to keep an eye on Folio. Peter On 04.03.2005 12:40:04 Peter B. West wrote: Jeremias Maerki wrote: Sounds very interesting. Would you consider sharing what you already have? This may help us in the general discussion and may be a good starting point. My problem is that I have to deliver working page breaking with keeps, breaks, multi-column, adjustable spacing etc. in a relatively short period of time. How short? -- Peter B. West http://cv.pbw.id.au/ Project Folio http://defoe.sourceforge.net/folio/
Re: Skype-conference on page-breaking?
Jeremias Maerki wrote: Sounds very interesting. Would you consider sharing what you already have? This may help us in the general discussion and may be a good starting point. My problem is that I have to deliver working page breaking with keeps, breaks, multi-column, adjustable spacing etc. in a relatively short period of time. How short? Peter -- Peter B. West http://cv.pbw.id.au/ Project Folio http://defoe.sourceforge.net/folio/
Re: [XML Graphics - FOP Wiki] New: FopAndJava2D
fop-cvs@xml.apache.org wrote: Date: 2005-02-22T11:07:06 Editor: 81.221.184.65 Wiki: XML Graphics - FOP Wiki Page: FopAndJava2D URL: http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D Documenting the Java2D proposal New Page: = Apache FOP and the Java2D API = This page describes FOP's design around the Java2D API. === PDF, PS etc. through Java2D === The above PrintRenderer can also be used to create PDFs or PostScript files by printing through JPS. The Graphics2D subclasses PDFDocumentGraphics2D and PSDocumentGraphics2D can indirectly be used for that purpose by writing a JPS StreamPrintService. ''(BTW this is the approach Peter West intends to take with his Defoe)'' Name change. The project is now called Folio, although SourceForge hasn't caught up with that yet. Repository now bkbits.net (BitKeeper). bk clone http://folio.bkbits.net/Folio Peter -- Peter B. West http://cv.pbw.id.au/ Project Folio http://defoe.sourceforge.net/folio/
Re: marketing Defoe
Jeremias, Do you disagree with the assessment? Clearly people might, but I didn't say anything I don't believe is the truth about the state of FOP. If it is true, isn't it fair to let newcomers know the state of play? Finn has already talked about a radically different approach in order to solve the large files problem, and I'm sure he will present you with a swag of patches to do just that at some time in the future. I just hope he doesn't do it so soon as to render Defoe moot. One of its underlying features will be what is effectively a stream parsing mechanism. It's acceptance, which I take to be a fait accompli, there being no other design contenders, will be particularly galling for me, in light of the the blanket refusal to consider it when I proposed it, as I still do. I think I have earned the right to speak my mind on these issues. Peter Jeremias Maerki wrote: Peter, it's ok if you make other people aware of your project but the way you did that in your last post disturbs me. We know that you disagree with FOP's approach, but I would have preferred a more constructive form of making Mark aware of Defoe. Maybe I'm overreacting...
Re: marketing Defoe
Glen Mazza wrote: (Don't let Peter rattle you, Jeremias--he's just jealous that I've found more XSL spec bugs than him. ;) You have a lead I am unlikely to overhaul. Our delays are mostly related to advanced issues concerning layout, and the type of parser used doesn't have much effect on this issue. Time will tell. So I don't share Peter's conviction that FOP is in need of a major design overhaul--or that Defoe's layout is as complete as it needs to be either, for the matter. There is no Defoe layout ... yet... Both sides have a lot of work to do. ...so yes, there is a lot of work to be done on Defoe. Glen Peter PS Thanks to Clay for the feedback.
Re: another nose for the grindstone
Mark, Project Defoe http://defoe.sourceforge.net/, formerly Fop alt-design, is focussed on a Java 2D renderer, robust and complete. By complete I mean, in particular, able to correctly handle last-page, keeps, table auto-layout and large files. Don't make the mistake of thinking that, because FOP has been around for a long time, it is only the place to be for open source XSL-FO development. Rather, ask why, if it has been around for such a long time, these problems haven't been solved. Don't make the mistake of thinking that all software problems are solved by simply applying more resources. Having said that, let me add that the project seems to have found its shepherd, in the form of Finn Bock. Many of the long-standing innovations of alt-design in the property handling have at last been introduced by Finn, who has the happy knack of being able to completely rewrite large chunks of FOP by applying a wide-ranging but complete set of changes. He may well solve FOP's remaining critical problems in the same way. The point is, that FOP needs a major design overhaul. I'm doing that at Defoe, and Finn is doing it, piecemeal, at FOP. His focus though is not on Java 2D, and getting a complete and robust implementation of the 2D renderer will depend on Finn's new design. If you want to know more about where FOP is headed, ask Finn. Defoe is Java 5.0 based. If that doesn't work for you, don't bother with Defoe. Otherwise, if you are interested in avenues for your XSL-FO development efforts, I am happy to talk to you. Peter Mark Brucks wrote: I'd like to join the fop development group. I've been an xsl/fop user for the last year or so (generating PDF), but several new projects I'm proposing have a need for a robust and complete awt renderer, and I'd like to devote some time to ensuring this happens. I have a little bit of time in the near term to commit to the project, and I hope much more time starting in the April time frame. I'd like to use the next 2 months to come up to speed, then dive in to serious work when more time is available. I need some advice. I've learned enough about xsl and fop to get my job done, but there are lots of holes in my knowledge base. I'd like to spend a little bit of time carefully reading the XSL spec. Should I read the XSL V1.1 working draft (in anticipation of things to come), or should I stick with the V1.0 recommendation (which I assume is what the new version of fop will implement). Do the development and design documents that are available on-line relate to the root/trunk/redesign version, or do they still describe the maintenance branch? Is there a development schedule or a prioritized list of features to be implemented? Is anybody else actively working on the awt rendered for the next release? Since this is my first foray into open-source development, any and all advice is welcome. Thanks - Mark Brucks
Re: start-indent inheritance
Jeremias Maerki wrote: I'm trying to figure out what the indent of the orange block under the block-container may be, or rather if our current implementation is really ok. It's clear that for the yellow block start-indent is 10pt. 5.3.2 says for FOs that don't generate a reference area (ex. fo:block) the following is true: Not quite. The following is true [i]f the corresponding absolute margin property is specified on the formatting object and the formatting object does not generate a reference area... start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width start-indent = 10pt = 10pt + 0pt + 0pt + 0pt The corresponding margin property is not specified, so start-indent is inherited_value_of(start-indent), i.e. 10pt. For the block-container a different rule applies because it generates a reference area: Same problem. If the corresponding absolute margin property is specified on the formatting object and the formatting object generates a reference area... start-indent = margin-corresponding + padding-corresponding + border-corresponding-width start-indent = 0pt = 0pt + 0pt + 0pt start-indent = inherited_value_of(start-indent) = 10pt. Then for the orange block the first formula is used again: start-indent= 0pt = 0pt + 0pt + 0pt + 0pt start-indent = inherited... = 10pt Now, it's interesting to note that XEP and AltSoft interpret this differently. XEP indents the orange block by 10pt while AltSoft indents it by 20pt. Go with AltSoft. You could also note that start-indent is specified as Inherited: yes which somewhat contradicts the second formula above. XEP seems to use the inherited start-indent for the block-container. AltSoft seems to do the same and even does the same for the orange block although rendering then orients itself on the reference area established by the block-container, thus indenting the orange block by 20pt. AltSoft is certainly wrong. The question is if XEP is right. :-) I googled a bit and indeed, there seems be a certain amount of confusion how this should be handled. Any thoughts? On 13.01.2005 16:07:02 jeremias wrote: jeremias2005/01/13 07:07:02 Added: test/layoutengine/testcases block-container3.xml Log: Testcase for checking start-indent inheritance across block-containers. Revision ChangesPath 1.1 xml-fop/test/layoutengine/testcases/block-container3.xml Index: block-container3.xml === ?xml version=1.0 encoding=UTF-8? !-- Copyright 2005 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id: block-container3.xml,v 1.1 2005/01/13 15:07:02 jeremias Exp $ -- testcase info p This test checks indents on block-containers. /p /info fo fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=5in page-height=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body fo:block start-indent=10pt fo:block background-color=yellowfo:block|fo:block/fo:block fo:block-container fo:block background-color=orangefo:block|fo:block-container|fo:block/fo:block /fo:block-container /fo:block /fo:flow /fo:page-sequence /fo:root /fo checks eval expected=35 xpath=/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/block[1]/@ipd/ eval expected=36 xpath=/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/block[1]/@ipda/ !-- TODO Complete checks after clarifying interpretation -- !--eval expected=35 xpath=/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/block[2]/block[1]/@ipd/ eval expected=35 xpath=/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/block[2]/block[1]/@ipda/-- /checks /testcase Peter
text-decoration
Fop-devs, In spite of the huffing and puffing, my original implementation of text-decoration was wrong. Such hubris. Currently being corrected in Defoe. Peter
Re: New year - update copyright years
Glen Mazza wrote:
{Sigh.} Jeremias, you are so particular--anyway,
Peter, will you please give Jeremias said greeting so
he can proceed?
Thanks,
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I've
got a script from Thomas to do that but I need a
good day to do that. :-)
Wish list:
G'day Jeremias.
I hope it works.
Peter
Re: Implementing text-decoration
Victor Mote wrote: Jeremias Maerki wrote: I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should be more like a set of enums with certain validation rules applied. I'm unsure about the approach. If anyone already has an idea how it should look like I'd appreciate any insight. My first idea was to implement a special property class (TextDecorationProperty) that handles the conversion of a ListProperty of NCNames to an internal set of variables while at the same time validating the enum combinations. I think my approach would work even if it look a bit awkward. But I wanted to check first so I didn't implement something really ugly. I think you are on the right track, and it is a curiosity to me why the standard writers did not create a separate datatype for this. The FOray implementation uses a pseudo datatype to handle text decoration, handled the same general way that keeps and spaces are: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-fotree/src/java/org/ foray/fotree/value/DtTextDeco.java?view=markup The class that creates and uses the datatype is here: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-fotree/src/java/org/ foray/fotree/fo/prop/TextDecoration.java?view=markup After taking this approach (i.e. allowing all of the variations to be stored together), text decoration was implemented properly. IOW, all of the other pieces were already in place, all I had to do was get the data stored and retrieved correctly. Caveat: FOray stores and retrieves properties using a late- or no-binding scheme, so the timing will be different, but I would think the general principle would be the same. And of course, alt-design had a solution for this, oh, a long, long time ago. It can be found in the usual place, and was even mentioned on the list. That's two solutions so far, and counting. Peter
Happy New Year
Greetings from the future. Happy New Year. Welcome to 2005. Peter
Re: Happy New Year
Glen Mazza wrote: 2005? Oooh--what's it like?--is everyone going around in space ships? ;) Glen (7 1/2 hours more to go) --- Peter B. West [EMAIL PROTECTED] wrote: Greetings from the future. Happy New Year. Welcome to 2005. Peter Fine, warm, scattered cloud. No visible spaceships. Pretty normal really. http://www.qtcu.asn.au/webcam/30minutes.asp Best wishes (and donations) to the tsunami survivors. Peter
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Jeremias Maerki wrote: On 28.12.2004 02:26:51 Peter B. West wrote: snip/ Did you find the reference to java.awt.graphicsenv in PJA? Just downloaded PJA. There's no reference in PJA other than in the javadocs for PJABufferedImage and PJAGraphicsEnvironment. Seems like the developer has to make sure that the system property is set (as could be expected). It's interesting to note that PJA subclasses SunGraphicsEnvironment and not GraphicsEnvironment. Like this they are dependent on Sun-private classes. So I saw. It's only for PJAGraphicsEnvironment. Where do the Sun-private classes come from? Where else have you seen a reference to java.awt.graphicsenv? Peter
Re: GraphicsEnvironment, GraphicsDevice and Graphics2D
Jeremias Maerki wrote: (not a real specialist in this area but...) On 26.12.2004 02:13:46 Peter B. West wrote: snip/ ... What puzzles me is the circularity of requiring a BufferedImage, with its implicit dependency upon getLocalGraphicsEnvironment(), which seems to be the only way to directly discover a GraphicsEnvironment. It's as though there is no formal way to introduce your own GraphicsDevices, apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf through the reliance on BufferedImage. Yes, I think there's no such thing, although I don't think it's necessary. The PDFGraphicsConfiguration and PDFGraphicsDevice is all that's necessary to support Graphics2D output to PDF. And PDFGraphics2D instantiates the PDFGraphicsConfiguration as necessary. If you want to replace the default GraphicsEnvironment you'd probably set the java.awt.graphicsenv system property accordingly. But that's most probably not something you will want to do as it has consequences on the whole AWT subsystem in normal operations. Did you find the reference to java.awt.graphicsenv in PJA? What am I missing? I don't know. What are you trying to do? Is this about changing font support for the PDFGraphics2D? Knowing that I might have some better ideas. I'm just trying to understand what I'm doing when I fiddle with GEnv and GDev. When I first looked at using Java2D methods for all rendering, I concluded that the GraphicsEnvironment was closed, because there seemed to be no independent pathway to the creation of a modified GraphicsEnvironment. That's why I was so excited when SVGGraphics2D was mentioned on fop-dev. Looking at the implementation, though, I see that the same problems exist. I don't know quite how to express my disquiet about this, but in PJA's terms, it amounts to the implicit dependency on the underlying native graphics rendering. q java.awt.Graphics methods such as drawLine (), fillOval (), drawString (),... are implemented in the default JVM with native graphical functions (except in some cases for Java2D) : That means that drawLine () finally calls a GDI system function on Windows or X11 function on a X11/UNIX machine even if the drawing is done in an off-screen image using the class java.awt.Image. This ensures the best performance for drawing graphics with Java. /q Maybe it also helps to look at PJA (http://www.eteks.com/pja/en/) to get a better understanding of what is involved in the whole thing. I just took a glance at PJA. I'll have a look at the 2D implementation code. PJA seems to have gone right back to the root of GraphicsEnvironment and built its own from scratch. However, q Starting with release J2SETM 5.0, AWT has been re-implemented on the Solaris and Linux platforms. The new Toolkit implementation provides the following advantages: * Removes the dependency on Motif and Xt libraries. * Interoperates better with other GUI Toolkits. * Provides better performance and quality. /q I'll ask eTeks what the implications of this are for PJA. Peter
GraphicsEnvironment, GraphicsDevice and Graphics2D
Jeremias or Thomas in particular, help!
I'm having trouble working out the relationships between the various
parts of Java2D, especially as regards the bits named above. At the end
of the day, the Graphics2D-GraphicsDevice combination is central to the
2D rendering process.
One instantiates a BufferedImage without specifically referring to any
elements of the GraphicsEnvironment, as for example in
PDFGraphicsConfiguration:
class PDFGraphicsConfiguration extends GraphicsConfiguration {
// We use this to get a good colormodel..
private static final BufferedImage BI_WITH_ALPHA =
new BufferedImage(1, 1, BufferedImage.TYPE_INT_ARGB);
// We use this to get a good colormodel..
private static final BufferedImage BI_WITHOUT_ALPHA =
new BufferedImage(1, 1, BufferedImage.TYPE_INT_RGB);
...
}
From the instance of BufferedImage, we can get a Graphics2D instance:
BufferedImage bufim = new
BufferedImage(1,1,BufferedImage.TYPE_INT_ARGB);
Graphics2D g2D = bufim.createGraphics();
From the Graphics2D, we get a GraphicsConfiguration and a
FontRenderContext:
GraphicsConfiguration grconf = g2D.getDeviceConfiguration();
FontRenderContext frc = g2D.getFontRenderContext();
The GraphicsConfiguration gets us back to the GraphicsDevice:
GraphicsDevice grdev = getDevice();
The GraphicsDevice won't take us back to its GraphicsEnvironment.
The implication of all of this, for me, is that a BufferedImage is not
created ex nihilo, but out of an understood context of GEnv, GDev and GConf.
GraphicsEnvironment provides a static method for retrieving the
underlying GraphicsEnvironment:
GraphicsEnvironment grenv =
GraphicsEnvironment.getLocalGraphicsEnvironment()
Given a GraphicsEnvironment and a BufferedImage, we can go the other way.
BufferedImage bufim = new
BufferedImage(1,1,BufferedImage.TYPE_INT_ARGB);
Graphics2D g2D = grenv.createGraphics(bufim);
All of which seems redundant, given that we can get to a Graphics2d
directly from a BufferedImage. I assume, though, that this is the way
to introduce a foreign GraphicsEnvironment, e.g.,
PDFGraphicsEnvironment. Is this a fair assessment?
What puzzles me is the circularity of requiring a BufferedImage, with
its implicit dependency upon getLocalGraphicsEnvironment(), which seems
to be the only way to directly discover a GraphicsEnvironment. It's as
though there is no formal way to introduce your own GraphicsDevices,
apart from the sleight-of-hand of creating a parasite GEnv/GDev/GConf
through the reliance on BufferedImage.
What am I missing?
Peter
Re: Merry Christmas everyone!
Bertrand Delacretaz wrote: Le 23 dc. 04, 20:56, Glen Mazza a crit : ...(OK, think I got everybody... ;-) Thanks Glen...actually to go the full i18n route, here's a special one for Jeremias: Jni wnachte! and Peter: Merry Christmas Mate! I reckon! Merry Christmas all. Happy Summer Solstice to Web Maestro Clay. Bertrand, make sure you come back for Christmas sometime. Sorry, no white Christmases, but air-conditioning if you're lucky. Frhes Weihnachten. Peter
Re: Large files.
Finn Bock wrote: The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes. [Victor] This model probably works fine if you never need to look ahead, but there are numerous examples (well discussed in the archives) where one does need to do that, the most obvious being automatic table layout. Peter's solution to that is pull parsing, which probably works, but forces an intermingling of interests that I need to avoid. My solution is to serialize the FOTree as necessary Did you notice that if a FOTree (or a fragment of it) is serialized to a preorder sequential representation with end markers, the preorder, postorder and child events can be fired directly from the input stream? Which is what Defoe does. Now let go of the notion of firing events, and we are in agreement. The SAX model is not relevant once the basic parsing is done. With a full-fledged stream parser, it won't be relevant at all. IOW the event based layout can work both of a normal parent/children linked tree and a sequential tree. Peter
Re: Large files.
Finn Bock wrote:
The loop can be stopped when we temporary run out of FO tree nodes
and restarted again when new nodes has been added. I suppose that the
FO tree can then be viewed as a stream of FO nodes.
[Peter]
I suppose so. And I suppose that making layout event-driven would
better fit in with the SAX event model. It just doesn't make sense
from the point of view of layout which is basically a top-down process.
By top-down, do you mean the visiting order of the nodes in the tree? Or
the structure of the code that does the layout? Like this:
process(Node n) {
preorder(n)
for (each child in n) {
process(child)
child(n, child);
}
postorder(n);
}
The traverse() code does the exact same as the process() code.
I noticed that, and wondered what you were getting at.
The
differences are:
- All people immediately recoqnize process().
- process() can use local variables to store state.
A major drawback of process() is that is darn hard to suspend processing
and then restart it. Our current getNextBreakPoss() code is a nice
example of just how hard it is.
The penny drops. There has always been a requirement for some form of
co-routine, and I see now what you are getting at. I think I see why
you mentioned this in the same breath as the SAX event model, but that
confuses the issue, I think. What you are proposing is compatible with
stream parsing, and in fact, fits quite well. Alt-design parsing
provides on-demand events to the FO tree builder, and is automatically
regulated by up-stream demand.
It seems to me that the events most natural to the layout process are
events in the FO tree, and that the main requirement for restarts in
the FO tree is to do with the inherent dialogue between FO and Area
trees. However, the discussion is too general, and my understanding of
the particular problems you are addressing is too vague, for me to make
meaningful comments.
Peter
Re: Large files.
Victor Mote wrote: Finn Bock wrote: The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes. This model probably works fine if you never need to look ahead, but there are numerous examples (well discussed in the archives) where one does need to do that, the most obvious being automatic table layout. Peter's solution to that is pull parsing, which probably works, but forces an intermingling of interests that I need to avoid. My solution is to serialize the FOTree as necessary (I do not have this working). The bottom line is that, if you conceivably need to see both the beginning and end of the input simultaneously (which we do), and you are writing so that disk space is the only constraining factor, you will have to either be prepared to re-parse the data (Peter's approach) or to serialize what has already been parsed (my approach). Victor, I think you may have misinterpreted an aspect of Defoe's design. The re-parsing (of attribute data) is only required for static-content and markers. Even then, it is not essential, merely the simplest way to achieve the result, given a stream of pre-parsed (in SAX terms) events. I'm quite happy with serializing the partial results where rendering cannot be resolved due to forward references. I don't see auto table layout and other localized look-ahead requiring this. I have never been able to see a third alternative. But I am always open to new ideas. I rather suspect that the current FOP design is oriented toward common use-cases rather than a comprehensive treatment that will handle all cases. Peter
Re: Large files.
Finn Bock wrote:
...
The problem with Keirons layout code (with respect to large input files)
is that it works top-down on the LM tree and thus require the creating
of the complete LM tree for the page sequence. To better fit within SAX
event model the layout process should also be event driven, triggered
f.ex by the endBlock() and character() events. That means that the
traversing of the FOTree cannot be easily done using recursive decend.
Instead the main loop over the FO tree could use a non-recusive tree
treverse like this:
public Element traverse(Node q, Node end, int mode) {
while (q != end) {
switch (mode) {
case FIRST:
// First time in the node.
preorder(q);
if (q.hasChildNodes()) {
q = q.getFirstChild();
break;
}
mode = NEXT;
// fallthrough
case NEXT:
// All children are handled.
postorder(q);
// Add the node to its parent.
if (q.getParentNode() != null) {
child(q.getParentNode(), q);
}
// fallthrough
case RESTART:
// Attempt to move vertically to next sibling.
horizontally?
if (q.getNextSibling() != null) {
q = q.getNextSibling();
mode = FIRST;
break;
}
// No sibling found, move to the parent to
// do postorder.
q = q.getParentNode();
mode = NEXT;
}
}
return null;
}
...
The loop can be stopped when we temporary run out of FO tree nodes and
restarted again when new nodes has been added. I suppose that the FO
tree can then be viewed as a stream of FO nodes.
I suppose so. And I suppose that making layout event-driven would
better fit in with the SAX event model. It just doesn't make sense from
the point of view of layout which is basically a top-down process.
BTW, datatypes.Node has getPrecedingSibling(), getFollowingSibling() and
many other doodads. First code I ever wrote for FOP.
Peter
Re: Another problem with Marker.rebind()
Victor Mote wrote: Simon Pepping wrote: Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every There is a certain wry entertainment value in watching the wheel being re-invented. Before I arrived, this problem was known as re-parenting. In my discussions of the issue, years after re-parenting was first discussed, there is even a diagram - shock, horror! - of the basic process proposed for Defoe (then the non-longer visible, but still present, Alt-design). Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. It does render the marker problem trivial, but so what. We have HEAD. Finn's off scratching his head vigorously, having just realized that there is a fundamental flaw in the design wrt markers. It will be interesting to see what emerges. Just by way of clarification, this is no doubt de facto true in the current FOP HEAD code, but, depending on the design, IMO it is not a necessity. Peter West and I discussed this some, probably around August of 2003. I thought at the time that a GraftingPoint interface which lived in the FOTree could be used to handle this concept without disrupting the independence of the FOTree. I am now of the opinion that the solution may be even simpler. Couldn't agree more, Victor. If you take the idea that the AreaTree is a view of the FOTree, so that Areas essentially inherit and/or derive traits from their generated-by FOTree nodes (instead of having bound values cached in them), You can combine both ideas. then the solution may be as simple as using some redirects when static content is involved. Bingo! This depends, in turn, on late binding (really, no binding) of the property values, ...and again... which does not appear to be possible with the current FOP design. ...and again. I am close to being able to demonstrate all of this within FOray, but I am not sure whether I will get it done in time for the upcoming 0.2 release, although it will have an independent FOTree. Thanks for pointing all of this out, Victor. It's nice to see some convergence on these ideas. Interesting that it must happen in Defoe and Foray. Peter
Re: Another problem with Marker.rebind()
Glen Mazza wrote: Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. Peter, are you saying that a pull parser is more computationally powerful than a SAX Parser--or is it just much more convenient? I don't think pull parsers can do more than SAX Parsers for the simple reason that you can implement a pull parser using a SAX Parser, no? Firstly, my apologies to all for the tone of my previous message. Too little sleep, too much gall. Defoe uses SAX for its stream parsing. Consequently, it's less computationally efficient. To use an extreme example, for many years compilers were less computationally efficient than coding with assembler. There are inefficiencies at every level of a computer system, from the microcode up. At any level, does the interface ease the development of solutions built on top? For most of my initial stint at FOP, I was obsessively concerned with micro-efficiencies, and I displayed my ignorance concerning this on many occasions. (Ask Jeremias or Joerg.) I have watched improvements in the performance of JVMs overtake my obsessions while I have been working on FOP. So much for not teaching an old dog new tricks. In spite of those concerns, I went with an inefficient parsing mechanism, because it mightily clarified the parsing process. As a completely unintentional side-effect, it gave me the tools to solve the really critical FOP performance problem on large files. This isn't going to be solved by micro-efficiencies on FO tree storage. Unfortunately, software developers are an intensely conservative lot. R J Neuhaus has a lovely term, the herd of independent minds. And he's not even describing software developers. It will be a long time before the SAX franchise falters. The curious thing is that Microsoft never went down the SAX road. They get by. Defoe is a big job, and I need all the help I can get, but I'll get there. Peter
Re: Good news: Jeremias has been elected as an ASF member!
Congratulations Jeremias. Well deserved. Peter Bertrand Delacretaz wrote: Hi FOP people, I have the great pleasure to announce that Jeremias Maerki has been elected as an ASF member at the last member's meeting during ApacheCon. I'm sure you will agree that this is well deserved, given all the energy that Jeremias has been pouring tirelessly in FOP, Batik, the XML federation and probably many things here that I don't know about. /me happy ;-) -Bertrand
Re: Unnecessary zipping and backups?
The Web Maestro wrote: BTW -- thanks *very* much for taking care of the alt-design tab, I greatly appreciate the effort in simplifying our site. Glad to be of service. If there are other things which anyone thinks can improve the site (e.g. consolidating pages, removing moved/incorrect/inappropriate content, etc.) please let me know. Clay, Let me say, Clay, thank you *very*, *very* much for taking care of the alt-design tab. Have I drawn your attention to the fact that I am *very happy* that you have taken care of this? (I have thanked Clay personally out-of-band for his work on this.) Peter
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor Mote wrote: Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Victor, Thanks, I'll keep an eye on it. I'll drop by the forum as soon as I get a chance. (Busy with Defoe atm) Peter
Re: Form Extension
Simon Pepping wrote: On Mon, Nov 01, 2004 at 08:50:06AM -0800, Clay Leeds wrote: Florian, On Oct 31, 2004, at 7:17 AM, Florian Hecht wrote: Hi FOP devs, I' ve developed a form extension for XSL-FO for an university project. It's an extension to FO like the fox extensions. With it you can declare and define the usual form elements like edit fields, radio buttons, check boxes, combo boxes, list boxes, comment fields and buttons. They are inserted into a document as inline objects, so that they flow like normal text. As a proof of concept I've extended fop-0.20.5 to support my form extension. I'm using the system around ExtensionObj to make fop understand my elements and I've extended the PDFRenderer to generate PDF documents that contain forms, that can be filled out and submitted just like normal HTML forms. At the moment the module for fop consists of a jar archive with the classes and a new batch file to start the processing (I'm not using the fop class as a starter, because I need to create a different renderer). The system works so far and is able to generate all of the form elements named above. Submit and reset buttons work as they're supposed to. I didn't test every layout situation for the form elements, so it might produce unexpected layout in some cases. As I said it's a proof of concept implementation and not a final product. The reason why I'm announcing this is that I will finish the project in a couple of days and I don't think I will develop the form extension any further. Maybe someone will find the sources usefull as a starting point or is even willing to develop it further. The sources and the precompiled jar archive can be found at my homepage [1]. I've also got an example fo document with my extension there, together with the resulting PDF file. So anyone who's interested can take a quick look at it. The paper I'm writing on this project will be released in couple of days (in German though, Studienarbeit) together with a little documentation on the form extension in English. Before you post on fop-user perhaps you/we should transfer it to a more 'permanent' server (since your e-mail will be in the FOP archives in perpetuity). I'm thinking that a good to place for this extension is on the 'Objects For Formatting Objects' Sourceforge project page[2] (assuming that Simon Pepping and/or other FOP committers agree). However, before we do that, we need to ensure it has the proper licensing. Please go to Apache Software Grants page for information on how to transfer[3]. I think it is a good project to be hosted by the OFFO project. The purpose of the OFFO project is to keep FO-related OS projects available for users and prospective developers. In view of the fact that you do not wish to develop it further, it should work out of the box for fop-0.20.5. Are you willing to answer questions from users? It would be good if you have some developer documentation, to give a prospective maintainer a headstart. It would be best if you release it under the Apache2 License. However, OFFO is able to host projects under any OSI approved Open Source license. You need to send the grant to me as the project maintainer; I will deposit it with the OFFO project. Note that I am not offering to do maintenance or to learn enough about the project to answer user questions. Currently OFFO does not have CVS services, but they can be set up if there is an interest. Alternatively, use Defoe. Defoe does have CVS services, and it does have the 0.25.5 maintenance branch as a module. I can give committer access to the FOP_Maint module to those like Florian, who have shown the ability and willingness to improve the code. There is a long list of developers of fixes and extensions to FOP who have been told (for how long now?) that 0.20.5 is frozen, and how many of them have applied their modifications to HEAD. Very few, I think. My intentions with Defoe, as you know, describe a completely different arc. It seems that HEAD may achieve 0.20.5 functionality in the near future, and make it to a release. In that case, it may prove useful to have a de-facto (De-foe-to) 0.20.6 functionality as a target for the first maintenance release . If Offo becomes a full-scale 0.20.5 maintenance site, with full hyphenation included, fair enough. While the Board pursues its current policy wrt licensing, e.g. with Rhino, there is no option but to home elsewhere if projects want to provide a complete service to users, so I expect to see more of it. Peter -- Peter B. West http://cv.pbw.id.au/
Re: AreaFactory patch
Andreas L. Delmelle wrote: All right, all right, maybe I'll just 'agree to disagree' in this case ;-) --mind you, *not* WRT to Exceptions, though... I declined to further the debate, but I'd much rather see GM read Sun's APIDoc for java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that FOP has no business throwing an 'IllegalArgumentException' or a 'FileNotFoundException', no matter how well the name seems to fit the error... (esp. the first, since it subclasses RuntimeException = unchecked) [*] On the topic of exceptions, and now that it's all over... I was puzzled by this discussion. Would anyone expect that Defoe would subclass SAXException for document validation errors? If not (it doesn't), why not? And if someone was inclined to write an FO processor using a DOM front-end, would you expect validation errors to throw subclasses of SAXException? The same fo file, with the same errors, could be processed by three different processors, using three different parsing methodologies, and the same validation errors would encountered. (OK, you can classify at least two categories of validation error, but I think the argument still applies.) SAX != XML parsing, let alone document validation. Peter
Re: Defoe
Clay, Thanks for the comments. I would be interested to see the alt-design doco running under the new Forrest regime before it is removed, because I would like to take advantage of your hard work in coming to terms with Forrest. It was difficult to get the documentation working in the original Forrest-based version, and I would like to see if, and how, it can be done in a newer Forrest. Peter
Re: [DOC] font-variant
Clay Leeds wrote: Unfortunately, I still have a few problems (see [1]), including a rather gaping hole in the FOP Compliance page (it doesn't show *any* content--d'oh!). I'm also working on some problems with various problems in the alt.design portion of the web site. The problems are most notably: - design/alt.design/xml-parsing.html (no content) - design/alt.design/properties/introduction.html (content but all sub-links have no content) Ah, were you perhaps hoping to eliminate these problems? It might, nonetheless, prove useful to solve them. FOP's documentation may use such methods in future. Peter
Re: Defoe
Thanks Clay. Please disregard deeply unworthy comment on a previous message. Peter Clay Leeds wrote: I'd be happy to help out! Of course, since it appears to be moving anyway, it might be easier for me to move your documentation to a new forrest install and go from there. Either way, I'm happy to do what I can. (IOW pile it on! :-p)
Re: Defoe
Victor, Thank you for the compliments. It's interesting to see the development of a multiple approaches, and the strength with which differing views are held. I've started a blog as a diary of Defoe development and, at the moment, my learning experiences with Java 5.0, especially Typesafe Enums and Generics. If you drop in there from time to time, you can see what I am up to. Have you considered one for FOray? Peter Victor Mote wrote: Peter: I too wish you the best of luck with Defoe and with whatever your future FOP involvement may be. One of my motivations with the modularization work was to make room for the competing ideas, mostly yours, to share what could be shared. This may help explain my frustration at your opposition to it (I didn't catch on until too late that your deal was all-or-nothing). At any rate, I wish to make it clear that I have high personal regard for you, and I consider it an honor and privilege to have worked with you. I thought of you a few days ago as I was building (again) a little event system for the FOTree system (in FOray this time). When I built it in FOP head over a year ago, it threw events for end-of-pageSequence and end-of-Document. When I built it on FOray a few days ago, I added an event for end-of-FObj. That way a really eager layout system like yours can grab it and go if it wants to. Its not exactly pull parsing, but it seems like a guy could build his queue from that and do whatever he wants to. That is the theory anyway. It took just a few minutes to implement. I am knee-deep in modularization (again), and although it will be a while before I get there, I am eager to either prove or disprove my theory about using an interface for the grafting of reference areas. I'll try to keep you posted through fop-dev as (or if) I make any progress. I certainly wish you great success with Defoe. Barring all of us working together with one mind (which has I think been well-enough tested), what could be better than to have multiple successful open-source implementations?
Re: Defoe
Fops, I originally thought I was replying to an offline message here. Hence the unusual tone. Peter Peter B. West wrote: Finn, No, it hasn't been made yet. ... Finn Bock wrote: Hi Peter, Did I miss the announcement? http://defoe.sourceforge.net/ regards, finn
[Fwd: Re: [Fwd: Re: Federation Status]]
I'll second that. Peter Berin Lautenbach wrote: Woo-Hoo!! Congratulations to all, but particularly Brian and Jeremias - a huge effort! -- Peter B. West http://cv.pbw.id.au/
Re: Defoe
Finn, No, it hasn't been made yet. I don't see much point in announcing it until I have a more substantial framework. The other developers are guys who have expressed an interest, but haven't actually become involved yet, so it's all pretty new. I've just set up a blog at http://www.livejournal.com/users/pbw/, but have not had time to bring the alt-design documentation across. NetBeans 4.0beta is still pretty raw, but apart from the evaluation version of JBuilder 2005, it's the only freebie that supports 1.5, so I'm running off CVS versions of that for now. I've mentioned Defoe to Jeremias and to Jrg in passing during other conversations. I don't want to be seen to be distracting Foppers, but it looks as though it's time to let the dev list know. You're doing fabulous work on FOP, btw. I'm jealous of your talent. Peter Finn Bock wrote: Hi Peter, Did I miss the announcement? http://defoe.sourceforge.net/ regards, finn -- Peter B. West http://cv.pbw.id.au/
Defoe
Fopsters, While I haven't wanted to make a fuss about it at this stage, given Finn's question, I guess it's time to let you guys (and Karen ?) formally know that I am in the process of setting up project Defoe on SourceForge. http://defoe.sourceforge.net/ It's alt-design under another name, but it is based on 1.5/5.0/Tiger, so it will be of no direct benefit to FOP in the near future, except as a test-bed for the alt-design processing structure. alt-design should probably be noted as a dormant branch, and me as an inactive committer. Peter
Re: [Fwd: Re: Performance improvement in property consumption.]
Original Message Subject: Re: [Fwd: Re: Performance improvement in property consumption.] Date: Fri, 15 Oct 2004 18:30:39 +1000 From: Peter B. West [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Finn Bock wrote: [Peter] Alt-design just uses a sparse array, constructed at END_ELEMENT. Space savings are progressively realized as the depth of the FO Tree reduces. Maximum consumption occurs at the points of greatest depth of the tree, minima at the end of each page-sequence. IIRC your sparse array does not just contain the relevant properties for an element (those listed in the spec under each fo:element), but the joined set of all properties relevant for all the allowed children. If this is correct, the sparse arrays stores more properties and uses more memory than my proposal does. The reason that the sparse arrays are constructed on the way back up the tree (at END_ELEMENT) is that the properties on all of the children have been resolved (except for markers and unresolved expressions), so there is no need to maintain any values that will not be used on *this* node. This, I imagine, is the same justification as for your reductions. Peter -- Peter B. West http://cv.pbw.id.au/
Re: [Fwd: Re: Performance improvement in property consumption.]
Peter B. West wrote: Finn Bock wrote: [Peter] Alt-design just uses a sparse array, constructed at END_ELEMENT. Space savings are progressively realized as the depth of the FO Tree reduces. Maximum consumption occurs at the points of greatest depth of the tree, minima at the end of each page-sequence. IIRC your sparse array does not just contain the relevant properties for an element (those listed in the spec under each fo:element), but the joined set of all properties relevant for all the allowed children. If this is correct, the sparse arrays stores more properties and uses more memory than my proposal does. The reason that the sparse arrays are constructed on the way back up the tree (at END_ELEMENT) is that the properties on all of the children have been resolved (except for markers and unresolved expressions), so there is no need to maintain any values that will not be used on *this* node. This, I imagine, is the same justification as for your reductions. Which is to say; no, the sparse arrays contain only properties relevant to the node itself. If not, it's a bug. Peter
[Fwd: Re: Performance improvement in property consumption.]
Don't mind the delay. Too many email addresses in a futile attempt to
keep one spam-clean. Apologies to Christian.
Original Message
Subject: Re: Performance improvement in property consumption.
Date: Thu, 14 Oct 2004 08:29:24 +1000
From: Peter B. West [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Glen,
The principles were applied in alt-design nearly two years ago now. It
is at least good to see that someone has applied them to HEAD.
Glen Mazza wrote:
--- Finn Bock [EMAIL PROTECTED] wrote:
So if we did this at the FO level, in effect, we'd
have to (1) store an instance variable of every
valid
property for each FO, given that we wouldn't know
whether the FOEventHandler's needs it beforehand,
and
Yes. Which is massively more efficient than storing
the exact same
properties in a PropertyList.
Why is it more efficient (I know it is, given your
metrics, but want to know why)--aren't you just moving
the values already stored in the PropertyList into
separate fields in the FO objects? Yes, you're
releasing the PropertyList's memory, but the elements
that the PropertyList previously stored are now stored
in the FObj.
So if PropertyList can be thought of as a C-like
struct holding the values of its FObj's properties,
what you're doing appears to be just taking that
struct's member variables and moving them to the FObj.
But, obviously, given the performance/memory boost
you're noting, PropertyList *can't* be regarded as a
C-like struct. Why? Could PropertyList be made more
efficient instead of this change--make it more like a
C-like struct?
It's a mixed bag, by the look of it. From the patch, applying to FOText:
+// The value of properties relevant for character.
+private CommonFont commonFont;
+private CommonHyphenation commonHyphenation;
+private ColorType color;
+private Property letterSpacing;
+private SpaceProperty lineHeight;
+private int whiteSpaceCollapse;
+private int textTransform;
+private Property wordSpacing;
+private int wrapOption;
+
+// End of property values
+
+public FOText(char[] chars, int start, int end, FONode parent) {
super(parent);
endIndex = end - start;
this.ca = new char[endIndex];
System.arraycopy(chars, start, ca, 0, endIndex);
// System.out.println(- + new String(ca) + -);
-textInfo = ti;
+}
+
+public void bind(PropertyList pList) {
+commonFont = pList.getFontProps();
+commonHyphenation = pList.getHyphenationProps();
+
+color = pList.get(Constants.PR_COLOR).getColorType();
+lineHeight = pList.get(Constants.PR_LINE_HEIGHT).getSpace();
+letterSpacing = pList.get(Constants.PR_LETTER_SPACING);
+whiteSpaceCollapse =
pList.get(Constants.PR_WHITE_SPACE_COLLAPSE).getEnum();
+textTransform = pList.get(Constants.PR_TEXT_TRANSFORM).getEnum();
+wordSpacing = pList.get(Constants.PR_WORD_SPACING);
+wrapOption = pList.get(Constants.PR_WRAP_OPTION).getEnum();
+}
+
Note the combination of simple fields for whiteSpaceCollapse and more
complex structures like CommonFont.
Alt-design just uses a sparse array, constructed at END_ELEMENT. Space
savings are progressively realized as the depth of the FO Tree reduces.
Maximum consumption occurs at the points of greatest depth of the
tree, minima at the end of each page-sequence.
Finn has gone a step further, and collapsed the property structures into
local variables, which is good for both memory consumption and speed, at
the cost of some more code. IIUC.
Peter
--
Peter B. West http://cv.pbw.id.au/
Re: PS Interpreter
Jeremias Maerki wrote: Thanks for the update, Victor. I absolutely want to have a look at this. So this is really the foundation to make Type 1 fonts available on the fly without generating font metric XML files by hand. Very cool. It'll be fun to see if I can get some basic ops working to paint some simple shapes to a Graphics2D interface. I'll be watching with interest. Peter On 07.10.2004 03:54:33 Victor Mote wrote: FWIW, the FOray PostScript interpreter is now able to successfully parse any Type 1 font that I have thrown at it, store the data structures, and retrieve them. This includes the ability to parse the encrypted portion of the font, whether in binary or ASCII hexadecimal. -- Peter B. West http://cv.pbw.id.au/
Re: Project offo distributes hyphenation pattern files for FOP
Moved from fop-user. Simon, Under which license have you set up the SourceForge project? Peter Simon Pepping wrote: Dear FOP users, In February 2004 a large number of hyphenation pattern files were removed from FOP's CVS repository due to licensing issues. These hyphenation patterns were contributed to FOP under licenses which allowed their free distribution, but under conditions which were felt to be in contradiction with the Apache license, under which FOP is distributed. Most files are licensed under the LaTeX Project Public License (http://www.latex-project.org/lppl/index.html), which requires that no modified version be published under the name of the original source file. For details see the FOP wiki page (http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003). I am please to announce that the hyphenation pattern files for FOP are now made available by the project `Objects for Formatting Objects' (offo) (http://offo.sourceforge.net/). They can be downloaded from offo's project page (http://sourceforge.net/projects/offo/). At this moment the homepage of the project is not yet ready. Therefore the overview of the hyphenation pattern files and their licenses is available from my web site, http://www.leverkruid.nl/FOP/hyphenation.html. It is also contained in the package file. Regards, Simon -- Peter B. West http://cv.pbw.id.au/
Re: Patches for FOP PDF and JPEG
Thomas, Could you clarify something for me please. As I understood it, the Java2D stuff assumes a normalized unit of measurement of 1pt = 1/72 inch. It provides float and double versions of the graphical objects, like Rectangle2D.Double and Rectangle2D.Float. The GraphicsDevice objects within the GraphicsEnvironment then transform measurements in the normalized form into device units. It is this normalization that allows for the predictable representation of of graphics objects on different output media. So far, so good? Was it your intention that the SVGGraphics2d environment provide such functionality? Is this still the case? Peter -- Peter B. West http://cv.pbw.id.au/
Re: Javasrc, JXR and documentation
Clay, Thanks for keeping this on the boil. The Forrestdoc link you gave me shows the Javasrc at a much greater level of integration than was visible when I last looked. My problem originally was that only line-number links were provided. In the current forrestdoc version, everything is linked in to comprehensive cross-reference web. Nice. The appearance of the the source text is not optimal, but there is scope in Javasrc to correct this, I believe. There are probably two levels of tuning. Firstly, syntax highlighting, and secondly. link presentation. The syntax highlighting variations (if any) would be Javasrc configuration options. The link presentation would be available through the CSS used to present the document. Most things of interest, and, AFAICT, all links are htmlized with a relevant class attribute, so it is feasible to select the link colour or colours for various classes to allow appropriate highlighting. Keywords, although emphasised in the text, are not given a class attribute, which is unfortunate, but may be tunable. The source html I used was generated by htmlize.el, an emacs and XEmacs module by Hrvoje Niksic. In order to use it, you will need to have an emacs or xemacs binary available to the build process. Forrestdoc looks the far better option. Peter Clay Leeds wrote: Peter, On Jun 29, 2004, at 7:04 PM, Peter B. West wrote: Clay, FYI, Java 1.4 javadoc tool supports a -linksource argument, which generates html of source files. However, the process seems to have pretty much the same restrictions as the Maven JXR - the only references are to line numbers, which is just about the most useless form imaginable. It might be of interest to someone at a later stage to look at extending the standard doclet to utilise Javasrc to perform that generation. Peter I've been hoping to get movement on the forrest front, then include the java doc stuff once I have xml-fop up running. As that's not moving along very fast, perhaps I can get a bit more information on what we need to do with the java doc front. Here's something I 'dug' up[1]. Looks like it's along the lines of what we're looking for, although I like what you've got on this page[2] better. Your version seems more accessible. However, you indicate: The problem is that there was no clean way to automatically generate the htmlized source. It's that supplementary facility that I'm looking for. What is the procedure used to generate the htmlized source? Could it be automated using gump or ant or something? BTW, what's the tool called you use to generate this? Web Maestro Clay [1] http://cvs.apache.org/~nicolaken/whiteboard/forrestdoc/ [2] http://xml.apache.org/fop/design/alt.design/properties/classes- overview.html -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: Jeremias' ideas about factoring out useful stand-alone elements from the combination of FOP and Batik are essential to the direction I am taking with layout and rendering, aside from being a Good Thing in their own right. Yes, I've pulled about 8 methods from the Renderer interface so far, giving Renderer implementors a little more freedom in how they choose to implement one. Also, I removed direct FOTreeBuilder.addElementMapping() methods which should HEAD a little bit more FAD-friendly (FAD, of course, doesn't have element mappings). The external user sets them in FOUserAgent instead, and HEAD's FOTreeBuilder reads from the FOUserAgent object to obtain them. The FAD version of an FOTreeBuilder would simply ignore this setting. This doesn't mean I'm trying to move to FAD's pull parsing--I'm not-- Shucks. but if I can increase the number of components you can use, so much the better. (To that end, notice the one-line of code in getDefaultHandler() in Driver that initializes FOTreeBuilder. If FAD's FOTreeBuilder equivalent can work with these arguments--a render type, output stream, FOUserAgent object--great! That would mean fop.apps package can be the same between two systems.) I think there are some possibilities here. A lot of what you are doing seems kindred (in spirit, at least) with Victor's approach. I'll take whatever I can get from FOP for FAD, and the more commonality the better. But there is a fundamental difference in approach to XML events in pull parsing, which liberates application processing to a degree which I don't think is appreciated by habituated SAX users. In FAD the scope of XML parsing is entirely circumscribed by the parser thread, which runs on-demand. All of the requirements for inputs, transformations, etc, are the same, because I am using SAX under the hood. But when a native pull parser comes along, say as a result of Andy Clark's work with NekoPull http://www.apache.org/~andyc/neko/doc/pull/index.html, XmlPull http://www.xmlpull.org/, JSR173 Streaming API for XML http://jcp.org/en/jsr/detail?id=173, or the WebLogic XML Streaming API http://e-docs.bea.com/wls/docs70/xml/xml_stream.html, I will happily ditch SAX. Whether the Streaming API will be JAXP compliant is a moot point. If not, it is another wedge between FOP and FAD. In general, I'm trying to move away from supporting direct manipulation of internal objects from external users: e.g., AreaTree.setWidget(), etc. and instead am placing the customization in FOUserAgent (or the xml configuration file, perhaps) for the internal objects to read. That way if an alternative implementation has nothing to do with widgets, it can simply ignore the setting in FOUserAgent without being forced to implement an architecture-breaking setWidget(). This also gives future implementors ability to completely revamp things internally without worrying about the API. The layout engine that I'm currently working on looks as though it will have three threads - a parser thread (which will disappear in a streaming parser), a layout engine and a renderer. Press button=Repeat The Area tree is built in lockstep with the FO tree. An area may provide the context for the resolution of properties on the descendants of the FO that generated that area. The integration is that tight. Furthermore, page layout begins with the start tag of a page-sequence fo:flow, not the end-tag. It is pull parsing that makes this feasible, and makes possible the solution of FOP's most critical problem - memory. It doesn't matter how long the page sequence is in FAD. /Press An API which is to accommodate both FOP and FAD must be able to span such fundamental differences. Incidentally, IIUC, the above is not to do with eager layout. That was a property of layout strategies, concerning how much *layout* context was examined before a final layout decision was taken. In my understanding, it related to the ability to adjust layout across multiple paragraphs or pages in order to find a better quality solution, as opposed to making those decisions based only on local layout information. The same decisions must be made in FAD. However, the first order of business for FAD is to get basic layout working, then demonstrate multi-columns with footnotes, marker processing with inheritance from static-content, floats, keeps, and last-page processing, in no particular order. Peter -- Peter B. West http://cv.pbw.id.au/
Doubled commit messages
Is anyone else getting double cvs commit messages? I assume I am subscribed under more than one address, but my guess at what the redundant address might be has proved fruitless. Peter -- Peter B. West http://cv.pbw.id.au/
Re: Doubled commit messages
Clay, Yes I had, but I had failed to spot the relevant details. Thanks for making me look again. Peter Clay Leeds wrote: Have you tried looking at the Long Headers (aka Full Headers, Extended Headers, etc.)? Looking at the Long Headers for both messages should provide insight into which address is 'extra'. -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Glen, I'm pleased that you think so, bit I believe it was the best course for me at the moment. Peter Glen Mazza wrote: An unfortunate decision. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Fopsters, I have been discussing with Jeremias offline the appropriateness or otherwise of my being on the XML Graphics PMC. On reflection, I had some reservations, and I have decided to withdraw my nomination for the XML Graphics PMC, on the understanding that I will continue to take a keen interest in the factoring out of the graphics components. -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Clay, Glen, et al, I'm thinking of moving FAD development to SourceForge. My differences in approach are much more significant than Victor's, so much so that I have nothing to contribute to the discussions about details of implementation in HEAD. Like Victor, I retain an interest in seeing my ideas incorporated into FOP, and it seems that Victor's move may have opened much clearer channels of communication, without muddying the waters day-to-day. Jeremias' ideas about factoring out useful stand-alone elements from the combination of FOP and Batik are essential to the direction I am taking with layout and rendering, aside from being a Good Thing in their own right. That interest motivated my nomination for the PMC, but disguised the underlying differences concerning FOP. However, the primary business of the XML Graphics PMC, for the immediate future, will be the development of HEAD in FOP, and while I am thinking about moving, it doesn't seem to me to be appropriate to be on the PMC. Peter Clay Leeds wrote: Glen is not alone in his expression of that sentiment. I too think that was an unfortunate decision, and I suspect that others share it as well. Perhaps it *might* help me and others understand why you've made this decision (then again, it might not--we might still think it's an unfortunate decision... ;-)). -- Peter B. West http://cv.pbw.id.au/
Withdrawal of PMC nomination
Fopsters, I have been discussing with Jeremias offline the appropriateness or otherwise of my being on the XML Graphics PMC. On reflection, I had some reservations, and I have decided to withdraw my nomination for the XML Graphics PMC, on the understanding that I will continue to take a keen interest in the factoring out of the graphics components. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
FOP FAD design approaches
Fop-devs, It occurs to me that some of the implications of the FAD approach have not been successfully communicated. Part of this may well be because of my own inadequate understanding of the FOP process. Before I continuing with this discussion, I had better ensure that my understanding of one important point is correct. Why does FOP process in minimum units of a page-sequence? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Meeting Bertrand
Foplings, On Monday last, the 5th, Jenni and I met Bertrand for coffee at Mt Coot-tha, one of the surface irregularities of Brisbane dignified with the name Mountain. It does, however, offer a wonderful view of much of the city and surrounds. Bertrand and family were preparing to depart for a drive up the coast to Cairns, with spot of whale-watching at Hervey Bay. It was peculiarly exciting to meet face-to-face one of my FOP colleagues, and underlines what a strange work environment we inhabit. Here's to good, cheap hypersonic travel. http://www.mech.uq.edu.au/hyper/hyshot/ Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [VOTE] PMC chair for XML Graphics
Jeremias Maerki wrote: So let's vote on the PMC chair for the XML Graphics project. We have two nominated candidates: [ ] I vote for Peter B. West as PMC chair. [ ] I vote for Jeremias Maerki as PMC chair. Simple majority will decide. If we get a draw we'll figure something out. I'm abstaining, in case anyone is confused by the above. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PROPOSAL] API Changes
Glen Mazza wrote: Team, ... 1.) Drop the apps.Driver class and incorporate its remaining code into apps.Fop. Reason: Fop appears to be a better self-documenting class name within user's embedded code. It's also a neat name for a product. User's code would move from looking like this: // Construct driver Driver driver = new Driver(); // Setup Renderer driver.setRenderer(Driver.RENDER_PDF); Result res = new SAXResult(driver. getContentHandler()); To this: // Construct FOP instance Fop fop = new Fop(); // Setup Renderer fop.setRenderer(Fop.RENDER_PDF); Result res = new SAXResult(fop. getContentHandler()); Does the lower look better--over the long term, will it make FOP more well known, more used? FWIW, FAD merged Driver into Fop some time ago. From memory, the only issues were to do with the AWT renderer and its re-start capability (which I gather is not functioning anyway.) While we're at it, what about moving Fop to org.apache.fop? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Javasrc, JXR and documentation
Clay Leeds wrote: Peter, Did you get a chance to try the procedure Nicola recommended[1]? I haven't gotten a successful build yet, but I'm still working at it. When I do, I'll try to do as he suggested. No, I've been too busy working on the FAD layout lately. BTW, how does Simon's recent Documentation[2] figure in to this? I don't know. I think the fact that Simon's docs are Docbook based will militate against linking in to the sources, but Simon would be in the best position to answer this. If it could be done, it would be a great boon to the documentation. [1] http://marc.theaimsgroup.com/?l=fop-devm=108680587917268w=2 [2] http://marc.theaimsgroup.com/?l=fop-devm=108844739724995w=2 Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Java text geometry
Christian, Sorry it's taken me so long to get back to you on this. What's UTA? Peter Christian Z. wrote: Hi Peter, I didn't have a look at your work yet. So perhaps there's no reason for me to speak up at all. I personally find the Java Text API hard to extend and not very modular. So here's my request. Could you please provide some kind of hook in form of an interface so that I can easily write a patch for UTA anytime? You'll also need some kind of attributed string like Java provides in its java.text package. Would be fine to have a place where I can grab the input in a well defined format and pass the result back to FOP. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Problems with URL encoding in FOP docs
Fops, In http://xml.apache.org/fop/design/alt.design/index.html there occurs the following link: a href=http://marc.theaimsgroup.com/%3Fl=fop-dev%26m=103890259919360%26w=2; The question mark and ampersand are encoded as expected. When I hover on this link in Mozilla, I get: http://marc.theaimsgroup.com/?l=fop-devm=103890259919360w=2 as expected. When I follow the link, I get the _encoded_ values in the location window, and the website tells me that URL with the _unencoded_ values is not available. When I manually change the URL in the location window to contain the _encoded_ values, it works. How do I fix this? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Javasrc, JXR and documentation
Clay, FYI, Java 1.4 javadoc tool supports a -linksource argument, which generates html of source files. However, the process seems to have pretty much the same restrictions as the Maven JXR - the only references are to line numbers, which is just about the most useless form imaginable. It might be of interest to someone at a later stage to look at extending the standard doclet to utilise Javasrc to perform that generation. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Bertrand? Bertrand? Are you still there?
Bertrand, I just noticed that you are heading to Australia, including Brisbane. Please get in touch when you are here. 0402 991 747 is my mobile number. If possible, let me know when you are arriving. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Validity checking
Fopsters, I notice that Glen has been progressively adding validity checking to FO elements. I'll take this opportunity to draw the attention of recent foppers to an earlier discussion of the relative merits of push vs. pull parsing in FOP. Alt-design (which I think I will just call FAD in future) uses pull parsing. The discussion went on over a more than one thread, e.g., http://marc.theaimsgroup.com/?l=fop-devm=103507639220269w=4 and re-surfaced in the discussion of marker handling in FAD, http://marc.theaimsgroup.com/?l=fop-devm=105455437221298w=4 The best encapsulation is probably the following discussion of the general principles, and their application to validation, with a nice instance of the effects of this validation in the case of simple-page-master. http://marc.theaimsgroup.com/?l=fop-devm=103785986329929w=4 Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Validity checking
Chris, It was wonderful, thank you. Drive-by tourism of the highest order. When I have some photos of the wedding and the tour I will post them. Peter Chris Bowditch wrote: Peter B. West wrote: Hi Peter - did you have a good honeymoon? -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
[Fwd: Re: [PROPOSAL] Finally creating the XML Graphics PMC....]
This went only to general. Must get into the habit of actually reading the To address. The discussion seems to have migrated to [EMAIL PROTECTED] Peter Original Message Subject: Re: [PROPOSAL] Finally creating the XML Graphics PMC Date: Fri, 25 Jun 2004 18:43:55 +1000 From: Peter B. West [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Jeremias, Thanks for the work on such thankless tasks as this, and thanks for the nomination. I have expressed some scepticism about the direction the Board is taking with TLPs, but it doesn't hurt to have a sceptic on the PMC. Like you, I'm sure, I don't particularly like administrative work, but I'm honoured to be nominated. I would urge new committers to consider indicating a preparedness (on or off line) to participate in the PMC. When I was first elected to the XML PMC as a FOP rep, I was quite up-front about the appeal of membership on my C.V., so don't be shy. I would also like to see you on the PMC, is only because it is fair to recognise the amount of effort you have put into bringing this TLP into being. If you want to bounce ideas about, or drafts of, the charter off me, please do so. I'll give what assistance I can. Formally, my votes for membership of the XML Graphics PMC are: Joerg Pietschmann +1 Glen Mazza+1 Jeremias Maerki +1 (conditional on his acceptance of nomination) Peter Jeremias Maerki wrote: Hi everyone, Berin thankfully pushed again and I'm taking the time for another round. Considering what I think is the general opinion, here's what I propose: 1. We create that XML Graphics PMC taking Batik and FOP under the new umbrella. I hope I don't have to explain again that nothing will change for our users. We will still use the XML project's infrastructure. 2. We will take Batik in even though the patient is in a suboptimal condition ATM. The PMC to-be-formed agrees to keep an eye on the project and help if any potential new committer bubbles up. When Batik's life energies come up to healthy levels again it shall be more strongly represented in the PMC as people come available. 3. I propose the following FOP people for the minimal initial PMC: Peter B. West, Jörg Pietschmann, Glen Mazza. I'd also propose at least someof the more junior committers but I don't know how anyone feels about that. Please propose any additional candidates as you see fit. I don't propose myself but I'm available if anyone proposes me. 4. I propose both Vincent Hardy and Thomas DeWeese from the Batik project as PMC members. I'd appreciate if at least one of the two accepted even if you can't actively participate in the development. You know it isn't much to do but it's important to have at least someone on board. I'll update the board resolution draft and set up a charter draft during the next few days (also peeking at the other works). The proposed PMC members are kindly invited to indicate whether they would be available for the post. Votes of support are requested for the nominations. If anyone is against this proposal (or parts of it) please speak up. We need to get this done. I appreciate any kind of help I can get. Jeremias Maerki -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PROPOSAL] Finally creating the XML Graphics PMC....
Peter B. West wrote: Formally, my votes for membership of the XML Graphics PMC are: Joerg Pietschmann +1 Glen Mazza+1 Jeremias Maerki +1 (conditional on his acceptance of nomination) Peter Jeremias Maerki wrote: Hi everyone, 4. I propose both Vincent Hardy and Thomas DeWeese from the Batik project as PMC members. I'd appreciate if at least one of the two accepted even if you can't actively participate in the development. You know it isn't much to do but it's important to have at least someone on board. Note that I will vote for Vincent and/or Thomas if they express an interest. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PROPOSAL] Finally creating the XML Graphics PMC....
Clay Leeds wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Being new to this VOTING thing, I'm a bit confused. I believe I've made it clear in a previous message, that I'm in favor of the PROPOSAL to create the XML Graphics PMC which will be the new 'home' of FOP and Batik, but I'm unclear on how this process works. I'm also in favor of the votes for membership expressed below (scroll down a bit for my specific votes...). What I'm unclear on, is the 'legal' difference between PROPOSAL and VOTE. I'd thought that the only time a VOTE really counts is when the SUBJECT includes VOTE. I've searched through the ASF docs, and the only place I can see PROPOSAL discussed, is[1], hence my confusion.: [1] http://www.apache.org/foundation/how-it-works.html Rules require that a negative vote includes an alternative proposal or a detailed explanation on the reasons for the negative vote. In any case, My VOTE(s) for this PROPOSAL (assuming they are appropriate now) are below: Creation of the XML Graphics PMC +1 Very sensible Clay. It was somewhat premature of me to vote on membership before we had a formal proposal for the XML Graphics top-level project. However, I assume the vote on members will still be valid when we get to putting a proposal forward, and voting on the acceptance of the charter. If not, we can ask for it again. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Offline
Fopfellows, I will be offline for the next week. I'm marrying Jenni tomorrow, and honeymooning in the frozen south of the South Island of New Zealand for a week. I'll post some photos to my web site when I get back. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Offline
Glen, Jenni thinks she likes you. Peter Glen Mazza wrote: Warmest Congratulations!!! (Can she program?!? ;) Glen -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Offline
Thank you all for your best wishes. Anyone who is still awake can check the weather in Brisbane at http://www.qtcu.asn.au/webcam/ Talk to you all in a week or so. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: Obviously, I would love to be able to output alt-design's layout to PDF without having to build a new interface mechanism. I think you have that already in the render.Renderer interface--which defines those methods that a Renderer must be able to implement. Review it and let us know where you think it needs modification. What I'm looking for is summarised in the following code snippet from http://xml.apache.org/batik/svggen.html DOMImplementation impl = SVGDOMImplementation.getDOMImplementation(); String svgNS = SVGDOMImplementation.SVG_NAMESPACE_URI; SVGDocument doc = (SVGDocument)impl.createDocument(svgNS, svg, null); SVGGraphics2D g = new SVGGraphics2D(doc); // Draw into g. For example: // Shape circle = new Ellipse2D.Double(0,0,50,50); g.setPaint(Color.red); g.fill(circle); g.translate(60,0); g.setPaint(Color.green); g.fill(circle); g.translate(60,0); g.setPaint(Color.blue); g.fill(circle); g.setSVGCanvasSize(new Dimension(180,50)); // The following populates the document root with the // generated SVG content. Element root = doc.getDocumentElement(); g.getRoot(root); // Now, display the document JSVGCanvas canvas = new JSVGCanvas(); JFrame f = new JFrame(); f.getContentPane().add(canvas); canvas.setSVGDocument(doc); f.pack(); f.setVisible(true); Note the SVGGraphics2D object, and the JSVGCanvas object for output. The graphics are constructed in SVGGraphics2D in the same way they are in any other Graphics2D object: g.fill(), g.setPaint(), g.translate() etc. SVG Generator can be added to an environment in which Java 2D graphics are already being produced, using the same instructions which are used on a Graphics2D object. The SVGGraphics2D object is used instead, and the same graphical operations are rendered in SVG. Substitute PDF for SVG. It so happens that the availability of such a substitution would be of great use to me, because I am constructing the layout in Java 2D terms, so that I can get it working with minimum agony. I don't hold out any hope that that will happen as part of FOP, but if it were to happen, FOP would have created a PDF library which could almost transparently be inserted into existing Java 2D programs. Do you see what I mean? The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 A nice summary, Glen, and one I have myself offered (the critical points of it anyway) to the debate before, with exactly the same result. I would add the following, which occurs after your quotes (3.1 Conceptual Procedure). quote The procedure works by processing formatting objects. Each object, while being processed, may initiate processing in other objects. While the objects are hierarchically structured, the processing is not (my emphasis); processing of a given object is rather like a co-routine which may pass control to other processes, but pick up again later where it left off. The procedure starts by initiating the processing of the fo:root formatting object. Unless otherwise specified, processing a formatting object creates areas and returns them to its parent to be placed in the area tree. (my emphasis) Like a co-routine, it resumes control later (my emphasis) and initiates formatting of its own children (if any), or some subset of them. The formatting object supplies parameters to its children based on the traits of areas already in the area tree, possibly including areas generated by the formatting object or its ancestors. It then disposes of the areas returned by its formatting object children. It might simply return such an area to its parent (and will always do this if it does not generate areas itself), or alternatively it might arrange the area in the area tree according to the semantics of the formatting object; this may involve changing its geometric position. It terminates processing when all its children have terminated processing (if initiated) and it is finished generating areas. /quote Note the order of operations; that's what alt-design will be doing. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
Jeremias, ... Jeremias Maerki wrote: We have it already (to a certain extent)unless I fail to see the point. We have: org.apache.fop.svg.PDFDocumentGraphics2D org.apache.fop.render.ps.PSDocumentGraphics2D org.apache.fop.render.ps.EPSDocumentGraphics2D Of course, it will take some more time to mature but the most important parts are there. I have even added support for multi-page generation in AbstractPSDocumentGraphics2D. Will be easy to add to PDFDocumentGraphics2D. At one point I did a proof-of-concept (not committed) to use the three classes above to create additional output formats for JPS (Java Printing System). Thanks for the info. You didn't miss the point, I did. I hadn't even looked at your svg or ps handling, and I had forgotten your earlier mention of the uncommitted proof of concept. I was talking concepts here anyway, and I'm exhilarated to find that you have already done so much work along these lines. Can you drop your code into a branch? One downside I see by using the Graphics2D exclusively is that you will (probably) lose the ability to pass through in-stream objects (JPEGs and SVGs) as-is to the target format. A JPEG will be decoded into a BufferedImage, an SVG will be rendered to a Graphics2D and reencoded as SVG, EPS might not make it into a PS file as-is anymore unless we create a PostScript interpreter (still on my very-long-term wish-list). On the image and foreign object front, although I haven't had time to think this through, I think there will be scope within the over-ridden methods to effectively do a pass-through. For layout, all we need to know is the laid-out size and positioning of the element. Images don't have to be fully rendered until they reach the renderer - PDF, PS, 2D. How this would work with those formats I don't know, because I don't know anything about image formats. You guys might want to talk to Hansueli Anderegg who's a fan of the exclusive Java2D approach AFAICS. I'd personally prefer to leave the PDF and PS renderer intact in HEAD for now. No problem with creating a second path and then seeing which is best. I don't see that happening, as I mentioned in my post. I was just excited by the notion of the SVG Generator, and wanted to rattle on a bit about it. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
Victor Mote wrote: Glen Mazza wrote: The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 Are you guys referring to me? My last word on the subject is here: http://marc.theaimsgroup.com/?l=fop-devm=107074009107318w=2 and it has never been answered by Peter or Glen or anyone else. Victor, I can't speak for Glen, but I wasn't referring to you. HEAD does not perform the sort of control-splicing between FO tree creation and area tree creation that is implied in the Recommendation as quoted. That's the old argument. It is no longer a concern of mine that FOP has returned to a monolithic design, but I think it is a bit unfair to the new developers to imply that the XSL-FO standard mandates such a design, at least with the reasoning that has been offered so far. Lest there be any doubt in the minds of new developers, the first sentence of 3.1 Conceptual Procedure (from which I quoted) is, This subsection contains a conceptual description of how formatting could work. This conceptual procedure does not mandate any particular algorithms or data structures as long as the result obeys the implied constraints. The reason I want to follow the model proposed is that I think it is the best way to go. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
[Fwd: CVS and Subversion]
Original Message Subject: CVS and Subversion Date: Fri, 11 Jun 2004 12:17:27 +0200 From: Dirk-Willem van Gulik [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] CC: Apache Infrastructure [EMAIL PROTECTED] In reaction to some worried emails related to some projects moving from CVS to Subversion. - Do not panic. - There is no ASF driven push (yet) for this move, no deadlines, no forcing. - It is you, the developers yourself, in each project who decide for -yourself- when and if it is time to go to Subversion - just let infrastructure know and they'll help you with the transition. - But I urge you to give it a look - it is a darn cool piece of technology; and it integrates very nicely with other tools. And although it is true that Subversion is young and has a serious footprint - it does have one important feature for projects like the ASF: it no longer requires user accounts in order to do commits. So in theory it is easier to secure a box and guard against changes under the hood; i.e. done to the repository directly. And thus tamper with our record of history - as right now developers -must- have r/w access to disk with the repository itself on the CVS machine. With about a thousand committers using several thousands of machines back home and a ssh/password based access controls it is a given that things leak over time. And one leak is quite enough. Thus reducing history/repository access alone is something the ASF as the legal steward of the code cares about a lot. (Those who where around a few years back during the last compromise of the CVS machine may recall the countless hours of work when we had to pour over the CVS records and backups to certify each and every file). It also means that subversion is easier to sandbox - thus further minimizing the damage from 'real' exploits. So all in all - it is a step forward; but yes a relatively young step - and that is why we are not yet making this an ASF wide compulsory change. Secondly Ben Laurie/infrastructure is working on a ASF wide Certificate Authority in the Bunker.co.uk using a machine specially donated by Ironsystems.com/Cliff Skolnick. Once that is in place we've added an other much needed layer which allows us to continue to scale in numbers of developers without suddenly needing a dozen full time sysadmins :) and it allows us to decrease the sensitive information, like password files, which need to be managed on a daily basis by multiple people on the machines even more. And ultimately it means that it becomes more and more possible to rely less on a 'unix root' admin - and means that we can handle the mutations from the then several thousands of commtiters on a timely basis. So in sort - and to stress: there are no deadlines, pushing or sticks to get projects to move from CVS to Subversion. Just the above carrots. But unless the early projects hit some major snags with subversion - DO expect the ASF to move there in the next two or three years - to allow us to continue to scale the infrastructure along with the number of developers and their demands while being good stewards to our code heritage at the same time On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Thanks, Dw, -- Dirk-Willem van Gulik, President of the Apache Software Foundation. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
SVG Generator
I recently asked the following question on the Java 2D Forum at Sun. quote The 1.4.2 API description for Graphics2D has: Some Graphics2D objects can be used to capture rendering operations for storage into a graphics metafile for playback on a concrete device of unknown physical resolution at a later time. Since the resolution might not be known when the rendering operations are captured, the Graphics2D Transform is set up to transform user coordinates to a virtual device space that approximates the expected resolution of the target device. Further transformations might need to be applied at playback time if the estimate is incorrect. I can find no further information about using this facility. I would like to be able to output to a virtual GraphicsDevice implementing PDF output. /quote Out of the blue, I was directed to the SVG Generator, which does for Batik what I have in mind for alt-design. Talk about serendipity! We have been discussing an integration of Batik and FOP under an XML Graphics umbrella, a discussion driven particularly by Jeremias. It has seemed to me for a while now that using the 2D API as a basis for rendering offers the possibility of a clean, or at least well documented and understood, interface between layout and rendering. In that case of alt-design, it is also the basis for manipulating the layout. I think the approach may offer benefits to HEAD. Providing a common interface between layout and rendering for PDF and PS would be beneficial for all, and would bring pluggable layout closer to realisation. The SVG renderer would virtually be in place already. Obviously, I would love to be able to output alt-design's layout to PDF without having to build a new interface mechanism. I believe that the same approach could be used with the structure renderers. With the current approach to RTF, it seems to me that a number of sacrifices have to be made. The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: CVS vulnerabilities?
There's a big push within Apache to adopt Subversion, and I suppose it will get to us in the near future. However, if we go there, I don't think it would be for this reason primarily. What are the security vulnerabilities of SVN? Nobody knows yet, and SVN has not been targeted. At least there is a major focus on security issues now with CVS. You could ask on [EMAIL PROTECTED] about the security status of Apache's CVS server and the relative security of SVN. All CVS updates are SSH tunnelled, AFAIK. Peter Clay Leeds wrote: I don't know who this should go to (they probably already know), but according to Reuters[1], the CVS system has some fairly significant holes. I know Forrest moved to SVN not too long ago. Have we thought of doing it ourselves? -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Javasrc, JXR and documentation
Clay Leeds wrote: On Jun 8, 2004, at 6:48 PM, Peter B. West wrote: The problem is that there was no clean way to automatically generate the htmlized source. It's that supplementary facility that I'm looking for. OK. I'll see what I can dig up on the subject. If you have any other keywords I can use in my search, by all means, send 'em my way! Clay, I would recommend emailing Nicola on the topic. I'm sure he would be only too pleased to tell you about the situation with Javasrc. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Javasrc, JXR and documentation
Clay, Do you have time for some documentation investigations? Some time ago, a project called Javasrc was in the process of migrating from SourceForge to Apache. Nicola Ken Barozzi [EMAIL PROTECTED] was the one who initiated the discussions with the Javasrc developers. The code was originally to go into Alexandria, a project on which development has now ceased. I recall some discussion about the use of Javasrc outside the context of Alexandria. There is an alternative, in the JXR plugin for Maven. Joerg may be of help here, as he seems to be a fan of Maven. My primary interest in this question is in generating cross-referenced source in html format, into which I can point from the web-site documentation. At the moment I have some html source that I generated using Xemacs, but that is extremely tedious. If you have time, could you ask a few questions about the best way of having such cross-referenced html sources generated as part of the process of web site creation? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Writing modes and Java
Oleg (or others who might be able to answer yes), Have you any experience with the use of recent Java versions for handling Hebrew text? I'd like to get the benefit of your knowledge if so. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Clay Leeds wrote: Peter B. West wrote: Shorthands have been fully handled in alt-design's properties for about 18 months now. Not true. How quickly we forget! The nasty ones are, notably font and border, but I just (re-)discovered that xml:lang wasn't, and I have implemented it. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Convenience branches. Was: Justification and line breaking
Chris Bowditch wrote: Peter B. West wrote: snip/ Simon, yes! That's what branching is there for. People seem to be afraid of it, but it is an enormously useful tool for just such situations. I think it's always a good idea to tag the tree immediately before a branch. Hi Peter, its not that I am afraid of branches, they have their uses, but I feel the project is at the wrong stage in its development for another branch right now. Branches invariably mean splitting development focus. Right now I want to focus on fixing the High priority issues with layout so we can do a release. If we flail around for another year or so then FOP may be dead in the water as other projects overtake it. Let's sketch a procedure for things like this. Someone proposes such a large patch again. We look at and realize that it can have a significant impact, but is worthwhile considering. The time frame for sorting it out might be anything from a week to a month or two. Tag the tree. Let's call it paragraph_patch. Tell the person proposing the patch - let's say Luca for illustration - to build his patch again based on the paragraph_patch. Luca checks out the tree using that tag. When he has it in a state to be examined, he submits the patch, noting that his work is based on paragraph_patch. Those interested in testing the patch create a branch, say paragraph_test, at the tag-point, paragraph_patch, checkout paragraph_test, and apply the patch. Is there any problem in applying the patch? No, because everyone is working with known and common versions of the files. Is there any impact on ongoing commits to HEAD? No. The committers (and Luca) still have valid HEAD trees on their machines, still track and contribute to the ongoing HEAD development. Let's say that Andreas commits some changes which affect Luca's work. Luca wants to merge them in. He asks for a merge. Impact on HEAD? Ask Andreas if his changes have settled down. Announce that the tree will be tagged at time X. Tag the tree; paragraph_merge_pt_1. That's it. Meanwhile, Luca requests that the paragraph_test tree be tagged (before_merge_pt_1). Disruption to HEAD - none. He locally merges from paragraph_merge_pt_1 into paragraph_test, and starts to sort out the conflicts. When he is done, he prepares a new patch against paragraph_test, which he submits. Committers who are tracking his work apply the patch to their copies of the paragraph_test tree. Disruption to HEAD - none. Patch errors - none. When the patch is ready to be applied to HEAD, the process of merging in from HEAD is repeated, relative to the last merge tag in HEAD. Committers announce that a merge into HEAD is pending, ask that commits to HEAD be suspended until this is done, and tag the HEAD tree; before_paragraph_merge. Luca merges locally into HEAD, and prepares a patch against HEAD, which he submits. This is committed and the HEAD tree tagged after_paragraph_merge. The paragraph_test branch is now defunct. Note that this description covers the whole development cycle of a major, potentially disruptive patch, through to integration into HEAD. Compare that to the dramas we have just been through (and are still going through - there seem to be two versions of HEAD out there on two committers' machines.) The responsibility for developing the patch rests primarily on the author and secondarily on the committers who perform testing and feedback. Had a procedure like this been in place, would the progress of Luca's patch have been more, less or equally disruptive? Obviously such a procedure is only *necessary* in unusual cases, but it makes sense to know how it is done, and it even makes sense to practise doing it on short cycle changes, so that things flow smoothly when the big issues come along. Just a suggestion. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: can't find default configuration file
Andreas L. Delmelle wrote: That was exactly what I meant, indeed. Not sure whether it's about the shell script interpreting the argument as one string, but anyway, it gets passed to the Java VM as one argument, and Java itself has no problems dealing with long file names... Arguments enclosed in quotes, either double or single, are passed as a single argument to the shell script. I'm not sure about Win CMD systems, but I believe that they do the same thing. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: can't find default configuration file
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Hi Peter, Arguments enclosed in quotes, either double or single, are passed as a single argument to the shell script. I'm not sure about Win CMD systems, but I believe that they do the same thing. Bam! This was the description I was looking for :) My initial wording was a bit off, just couldn't get it expressed right (could 've known that it would be more the OS than the shell script that does the actual interpreting) Andreas, It is in fact the shell, because your CLI system interface is also the shell. It interprets the arguments, then forks another shell which execs the binary command or interprets the shell script. As far as I know, CMD works the same way. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fonts
Glen Mazza wrote: Peter B. West wrote: I wrote: The latter is outside my scope of knowledge (but sounds messy ;)--as for the former, what font-specific methods (and their signatures) do you see us needing to add to our render.Render interface (which declares the minimal methods needed by layout to interact with a renderer)? getFontMetrics()? isFontSupported()? (Currently, there is just a setupFontInfo() in this interface, which, as you say, seems nonideal--layout feeding the renderers the FontInfo.) At the moment, I don't see any font-specific methods required. (Still learning...) But wouldn't we need to add some form of isFontSupported(fontName, ...) to the Renderer interface? AFAICT, the XSL font-family property allows me to specify any font I want, so long as it is supported by the RenderType I chose. So if I invent a new RenderType, say Glen Document Format (GDF), and invent a new font for it, Glen Font, isFontSupported(Glen Font) would return true for the -gdf output type and false for the -pdf output type. Then, layout would use that boolean value to determine whether it needs to fall back to a backup/default font. That would be covered in the combination of getFont(...) and selectionStrategy. If the selection strategy excludes intelligent font substitution, and the given font family is not available, return null. If intelligent substitution is allowed, then let the renderer select another font family. It's worth reading the relevant parts of the Fonts section in the CSS2 spec for some insight into the recommended font selection strategy. XSL-FO adds another twist through font-selection-strategy. The font-family property returns a list, the idea being that a series of family-names or generic-names can be tried in sequence to resolve a font. I'll have to read the CSS2 description again to determine exactly how . Also, (this point I'm less certain on) a getFontMetrics(fontName) of some sort would be needed so layout can determine how much space Mary had a Little Lamb would consume using my new font on the defined output type, correct? getFontMetrics() could be centralized in one place instead of being renderer-specific, but if so we may need to handle the issue of multiple renderers possibly having the same name for a font type but different metrics/meanings for them. (E.g., courier new having different sizes in awt than it would in pdf, or a render type short-circuiting a popular font that it doesn't support to a similar supported one with slightly different metrics.) The font metrics would be implicit in the Font (or FopFont) object returned from the renderer. Having the renderers (explicitly or implicitly) returning the Font object ensures that the layout's notion of metrics is the same as that of the renderer. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fonts
Victor Mote wrote: Peter B. West wrote: ... What I'm exploring is the possibility of going in the opposite direction. That is, using the Interfaces and Classes of java text layout as a model for FOP layout, even if the implementation is FOP specific. That way, when the Java model *is* adequate for FOP's use, it is a trivial matter. The 2D model of text layout seems very powerful. This is only opposite in the sense of how the abstraction works. Your approach is pretty sound, and, assuming that you can solve the embedding problem, has some merit. However, there is no reason that the isolated Font logic can't use the awt objects that you are interested in to do the work behind the interface that FOray is building (or something similar). By isolating all of this code, you can have your cake and eat it too. You can use awt if, when, and how much it really makes sense, and you can do all kinds of other stuff as well for places where awt is inadequate. For example, awt gives access to the OpenType tables, but really doesn't do anything with them. FOray wants to use that information, and I assume that FOP will eventually want to also. So, why limit yourself to awt? As I said before, even if awt were perfect, there is still value in hiding it, especially during a refactoring stage. I am interested in the 2D approach for a couple of reasons. Firstly, because I want a testbed for alt-design layout sooner rather than later. Secondly, I was looking for a approach to fonts and layout that was not PDF-centric and that might be familiar to new folks coming in, so the idea of modelling it on 2D appealed. Clearly, there is nothing of overwhelming relevance to HEAD in either approach. ... Yes, and the renderer gets that information from the Font, which is still the same Font, and has no idea who is using it or why or how. I don't deny that the concept I have described as RenderContext (you may have been off-line when we discussed this about a year ago) may affect layout. Those differences must be considered during layout (but the logic of handling them should not be done by the layout classes). RenderContext describes the capabilities that are available, presumably what fonts are available in this context, but could also include other things (can't kern, can't do letter-spacing, can't stretch text, etc). AFAICT, PDF and PostScript use the same RenderContext, but if there are differences, then they can each have their own. Once these capabilities are defined, they must be considered as the FOTree is built, and as layout is performed. So, while the Font is always a constant, it needs to be filtered through the lens of the RenderContext before it can be used properly. That is probably why the Font stuff ended up in the Render classes. And that is (part of) why I think, as FOP grows up here, it is important to distinguish between the Renderer and the RenderContext. java.awt.font.FontRenderContext performs this function for 2D font rendering. The arguments to the constructor are the AffineTransform for scaling typographical points to renderer pixels, and the booleans isAntiAliased and usesFractionalMetrics. If you'll give me a few weeks, I hope to be able to show you what I seem unable to sell with words. It will be good to see what you come up with. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Justification and line breaking
Simon Pepping wrote: ... I do not believe that the patch is mature for committing to the trunk code. See above. Luca, do you share my view? If I see it right, then Luca should work on his patch some more. Perhaps others could help with that work if he would want that. In such a situation it may be a good strategy to commit the patch to a branch of the HEAD of the trunk, so that it can be developed without problems with other work. Simon, yes! That's what branching is there for. People seem to be afraid of it, but it is an enormously useful tool for just such situations. I think it's always a good idea to tag the tree immediately before a branch. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Justification and line breaking
Glen Mazza wrote: --- Simon Pepping [EMAIL PROTECTED] wrote: Errr--I wouldn't want additional branches in CVS just for the sake of a patch--they tend to become permanent. Luca working on his local machine, or using something on SourceForge may be a better idea. It's just Monday right now--we can wait a few more days. Glen, branches are only as permanent as you make them. They're a tool, and with the CVS-aware IDEs out there, they are increasingly easy to use. (Until we're Subverted, anyway. Not a comment on the product itself, just the expected level of third-party support.) Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Fonts
I have been exploring the way fonts are handled by Java as part of setting up a Java layout engine and renderer. I have committed a new class - org.apache.fop.render.awt.fonts - as a first cut at a fonts database for this application. I will attach the class description to this email. The focus of the Fonts class is to provide the facilities required by the Recommendation. The Rec and the CSS2 spec talk about the User Agent having a database of known fonts, and the new class is a sketch of this requirement. The work is far from complete, but out of the WIP the lines of an interface for such a fonts database start to emerge, for me at least. The database must be able to match a font given family name style - normal, italic, oblique variant - normal, small-caps weight - normal, bold, lighter, bolder, 100 - 900 stretch - ultra-condensed - ultra-expanded size Java font handling can match on family name, style and size directly and, with the fonts commonly available, on variant, weight and stretch only by constructing virtual fonts. The database must be able to provide a complete set of selectors for each of the system-fonts caption, icon, menu, message-box, small-caption, status-bar. Given the scope for the User Agent here, Java font handling can manage this. The database must support the generic font families serif, sans-serif, monospace, cursive and fantasy. This requirement is both system and installation dependent, but serif, sans-serif and monospace are available as logical fonts in Java. Cursive and fantasy fonts support will depend on available fonts, but individual renderers can check for the availability of a number of fonts known to fall into these categories. I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer. This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF. Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry? I'll try attaching the Javadoc description from org.apache.fop.render.awt.Fonts, as the included HTML may cause problems otherwise. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html Java font selection is based on family names. It seems that Java handles font mapping something like this:br Given a set of physical fonts like, e.g., Arial, Java reports them as pre font face: Arial logical:Arial family:Arial PSName:ArialMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Cursiva logical:Arial Cursiva family:Arial PSName:Arial-ItalicMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Negreta logical:Arial Negreta family:Arial PSName:Arial-BoldMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Negreta cursiva logical:Arial Negreta cursiva family:Arial PSName:Arial-BoldItalicMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM /pre There are other Arial forms, e.g. Arial Black and Arial Narrow, but they fall into different families, as indicated by the font name. java.awt.font.TextAttribute defines a number of TextAttribute constants, and querying a Font object via getAvailableAttributes() will provide an array of attributes available on the Font. pIt seems there is a common set available on both Type1 and TrueType fonts in 1.4.2; viz FAMILY, WEIGHT, POSTURE, SIZE and TRANSFORM. Note that style is reported as PLAIN on all fonts, irrespective of the actual style according to the font name. pSIZE works as one might expect. WEIGHT is supported directly only for the weights provided in the set of family fonts. In the case of Arial, only REGULAR and BOLD. The same is true of POSTURE: REGULAR and OBLIQUE. There seems to be room here to experiment with virtual fonts. A virtual Arial font might be constructed
Re: Fonts
Glen Mazza wrote:
(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of
my current work with Java fonts. I'm afraid that I am still convinced
that font handling is properly the preserve of the renderers. The
layout engine needs only the font metrics, even for Java-based
layout. As far as layout is concerned, the glyphs could all be
Wingdings, as long as the metrics are right. The other required
information is that relating to font selection, as discussed above.
The logical home for font selection information is the renderer.
I see no problem with this. Ideally, anything renderer-specific,
including fonts, should be in the appropriate fop.render.{rendertype}
package.
This is not to say that, once a clean fonts interface has been
developed and implemented in all of the renderers, a further level of
abstraction cannot be applied to bring all of the information under
one umbrella. However, consider the problem of creating a new
renderer. Fonts are inherently renderer specific. It may be that
those fonts are shared between more that one renderer, but that fact
is incidental to, e.g., the common ancestry of PS and PDF.
If any render type relies on the fonts of another render type (e.g. PS
using PDF), we can have it import or subclass the font libraries of that
render type. (E.g. render.ps. code would import, say,
render.pdf.font.xxx classes.) The dependencies are better
self-documenting that way, IMO.
This seems to be the pivot around which both approaches can coalesce.
As I look at this for longer, I see that my initial notions about the
requirement for fonts are compatible with the generics that Jeremias and
Victor are working towards. Those are, it seems to me, a set of
handlers for different types of Fonts - Type 1, TrueType, OpenType,
Metafont, Framemaker fonts, whatever.
Which is more sensible - writing a renderer's font handling to a
common renderer font interface as an integral part of the renderer
implementation, or discovering the fonts quirks of this particular
renderer and adding them separately to a central font handler/registry?
The latter is outside my scope of knowledge (but sounds messy ;)--as for
the former, what font-specific methods (and their signatures) do you see
us needing to add to our render.Render interface (which declares the
minimal methods needed by layout to interact with a renderer)?
getFontMetrics()? isFontSupported()? (Currently, there is just a
setupFontInfo() in this interface, which, as you say, seems
nonideal--layout feeding the renderers the FontInfo.)
At the moment, I don't see any font-specific methods required. The
basic methods are
FopFont getFont(String family, enum style, enum variant, enum
weight, enum stretch, float size, enum selectionStrategy);
FopFont getGenericFont(enum type. enum style, enum variant,
enum weight, enum stretch, float size);
FopFont getSystemFont(enum type);
where enum is probably an int in all cases. selectionStrategy
determines whether, e.g., intelligent font substitution occurs if the
family doesn't have an exact match.
Individual renderers would access their own databases of available
fonts, and make their own decisions about what comprises a generic font,
what comprises a system font, and how to build virtual fonts if
necessary. This functionality within the renderers could be built on
top of the Type1, TrueType, etc. versions of FopFont. However,
individual renderers may need to vary the outcomes. For example, PDF,
although it uses Type1 and TrueType fonts, needs to express them
somewhat differently. Consider that a throw-away comment; I don't know
how PDF uses these font types.
Take the Java renderer. By including appendedfontpath in a new or
modified font.properties file, I can add new Type 1 or TrueType fonts to
the JVM. Let's say I find a Garamond font when I start up. Does it
qualify as a serif font? As a fantasy font? That sort of information
can be built into the relevant underlying font handler, but I can see
that individual renderers might want to override some methods in order
to make their own Quality Of Service decisions. See the Note under
auto in 7.8.3 font-selection-strategy in the 1.1 Draft.
What I have said qualifies as a central font registry in a loose
sense, which may be refined later. E.g., QoS information may
progressively be moved into the underlying font type handlers. However,
it seems to me that the final decision is with the renderer, and it is
the renderer that should be queried when the FO tree is being built and
fonts resolved.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Justification and line breaking
Luca, Do you know of a web-accessible version of the paper, or summary of the algorithm? Peter Luca Furini wrote: Hi all I am still thinking about justification and the more general problem of line-breaking, and I have come to think that it's quite strange that the LineLayoutManager should make choices about breaking points using only the information provided by the TextLayoutManagers, while it should have a wider knowledge of all the text. (I see bug 28706 as an example of this strangeness: the LLM wants the TLM to say if there is other text after the returned BreakPoss, but the TLM doesn't know of the other TLMs' text) At the moment, lines are built one at a time, and in normal cases only underfull lines are taken into account: as both bpDim and availIPD have .min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen one is simply the last short BP returned by a TLM. Even if bpDim had .min != .max, the choice would be made between a few alternatives for the current line, without considering what will happen next; this could generate an output alternating tight and loose lines, which is not very beautiful. So, I have tried to implement Knuth's line-breaking algorithm [1], which calculates breaking points after having gathered information about a whole paragraph. Here are a few advantages of this algorithm: - first of all, the output is very beautiful; there is not a big difference in width between spaces in consecutive lines, and the max space width is smaller than before - the interaction between LLM and TLM is quite the same; the TLM returns a different kind of objects, much smaller - the TLM code is simplified a bit, as it has no more to handle leading spaces, or calculate flags (which IMO are rather line-related than text-related) - the LLM now can quite easily handle properties such as text-indent, text-align-last, word-spacing and letter-spacing Could I open a bugzilla issue and attach a patch? It would be quite a raw patch, as I took some short cuts to make it work and there could be some useless variables, anyway it works and could be used to show the quality of the output. I have tested it with text-only blocks, so I don't know what could happen in more complex situations. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Chris Bowditch wrote: Clay Leeds wrote: Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... My understanding is that thanks to the property work earlier this year by Glen, Finn and Simon, that properties are 95% there, including shorthands. Admittely I didnt follow their work very closely, so could be wrong about this. Im sure Glen will interject and correct me on this if I'm wrong. I do get burned when the work on properties is mentioned without any acknowledgment of the influence that alt-design has had on HEAD's properties development. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Clay Leeds wrote: [EMAIL PROTECTED] wrote: Clay Leeds [EMAIL PROTECTED] schrieb am 19.05.2004 01:03:19: It would be interesting to compare some RenderX example output between the two^H^H^H three (ArndFO, fop-0.20.5, fop-1.0Dev)... I suspect there may be other significant differences as well, with performance, heap, etc. Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... Shorthands have been fully handled in alt-design's properties for about 18 months now. Then again, the more I think about it, the more it seems like Peter's train-of-thought RE: FOP development destabilization. 'We' could be working on FOP development, but instead we're talking about Arnd's (and Victor's) development efforts (I have every reason to believe it is everything he says it is), and discussing how the grass may be greener on the other side of the fence. That's true. So let's all get back to work. 8-) From Peter's mail: The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. I don't think what I did proves your point. Even though it worked for me this time, it was a high risk (ok, since I was always prepared to treat this a fun project, no risk). It was really a gamble, one I wouldn't have done under other circumstances - for example not if producing an FO formatter had been our business then. I suppose when you look around, you will find much, much more failed rewrite projects than failed incremental projects. In any case, I really don't think you can compare a one-person effort to that of a distributed group. Also, I believe this is rather a generic software-development question. If you think you do see the light at the end of the tunnel for the FOP rewrite then by all means go for it. That's interesting. My view on alt.design has pretty much always been one talented guy working on the other side of the world, and coding FOP the way he always wanted to. No distractions or lengthy discussion (albeit frequently contributing insightful posts to FOP-Dev -user). I haven't been keeping tabs on the status of alt-design lately so I don't 'know' where it is at present (I'll check the status page directly). That won't do you much good, as I haven't updates the docs for some time now. I'm currently working on layout, using Java's facilities (including 1.3 and 1.4) for the layout engine. I'll update the pages as I make progress on this. Btw, I'm now in the dark about the way the web pages are being maintained. It's been a while since I was involved in the discussions about Forrest and FOP, primarily around using Javascript in pages. I'll read the docs docs again. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Java text handling
Do any of the list denizens have experience with Java font handling and 2D text layout? I'm new to it, and would like to be able to bounce questions off someone further up the food chain, on or off-line. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Clay Leeds wrote: Peter B. West wrote: Shorthands have been fully handled in alt-design's properties for about 18 months now. Glad to hear it! One of these days, I'll have to build alt.design from source so I can see all of your hard work. I notice that it uses a non-ant system of building, so I may get back to you on how steps to proceed with the build (unless the steps are outlined and/or linked from the site :-)). It now uses Ant, so building is pretty straightforward. That's something else that will need updating in the docs. Btw, I'm now in the dark about the way the web pages are being maintained. It's been a while since I was involved in the discussions about Forrest and FOP, primarily around using Javascript in pages. I'll read the docs docs again. Peter No problem. I think this is something *I* can handle... ;-) I recently spent some time figuring out Forrest. I haven't completed all of my travels, however, as I still get errors when I do a forrest run. However, I do understand the format itself pretty well, so if you can give me 'before' and after (or a diff would be fine, I can commit the necessary changes--committership has its privileges... don't worry, I won't touch JAVA code 'til I've spent some time hashing things through!) Otherwise, you could always just edit the XML source files the way you like. That should work just as well. Once the edits have been committed, running forrestbot should do the rest (of course we'll have to replace breadcrumb.js--D'oh!--as I think it still gets clobbered when forrestbot runs). I'll send you diffs and refer any questions I have to you. Thanks Clay. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: ANN: FOray
[EMAIL PROTECTED] wrote: In my formatter, I have implemented modularized layout. From the start, I was sceptical, and I was indeed tempted several times to throw the concept out of the window because it got in the way, but in the end it was always possible to maintain the separation of concerns between different kinds of layouters (BlockArea, Table, Page, and List for example) even though the interaction is admittedly complex. And, yes, it's sometimes hard to follow the logic by staring just at the code - which I prefer to using debuggers. To summarize my impressions from this: 1. I would do it again this way. 2. Maintaining clean separation of concerns *forced* me to redesign my layouter interfaces several times when I added new functionality, but I gained an implementation that I still understand clearly in its entirety even I cannot work on it for a week. 3. The only place where I have difficulties after some time off is my BlockAreaLayouter which is one very large chunk of code. Maybe it's even worth factoring out a LineAreaLayouter, though I'm not sure of it - the interaction is really tight. 4. It's too early to estimate how much modularized layout will hurt performance in the end. My gut feeling is: not much, and it's probably wort it. So, from my own experience I can only encourage you to go forward with your plan. For me, it worked so far. Let's see if the XSL rec turns up more nasty surprises... Arnd, I think you are talking about different modularisation contexts here. You might want to clarify this part of the discussion with Victor. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Incremental vs rewrite
The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: ANN: FOray
N.B. CC'd to [EMAIL PROTECTED] follow-up to fop-dev Victor Mote wrote: Dear FOP Developers: After considering a return to FOP development, and briefly discussing the pros and cons with those whom I consider to be the FOP development leaders, I have decided to partially fork FOP into a sourceforge project called FOray: http://foray.sourceforge.net/ The main reason for this is that, at the moment anyway, my development goals are quite different from those of FOP's development team. It is likely that my return to FOP development would be a net disruption to the project, which is not my intent. Instead, my hope is that this vehicle will allow me to continue to get my real work done and still cooperate with the FOP development team. I hope that no one will think that I am recruiting here. I simply thought it would be rude for you to hear about this some other way. I wish you all success. Without speculating at all about the reasons for Victor's decision, I can tell you that I have considered moving alt-design to SourceForge. The reasons are two-fold. Firstly, and most importantly, there is the remote possibility of garnering some financial support for alt-design's development. For those of you who may not yet know, SourceForge has implemented a means for donating to projects or specific developers. The attractions of this idea I need not comment on further. My second reason was to clear the FOP waters by physically separating alt-design from HEAD development. My approach to testing alt-design's layout is to use Java facilities as much as possible. This will cause even further divergence from HEAD, at least initially. Moving to SourceForge will clarify the development lines of FOP HEAD for those who are considering involvement in the project. Such a move would, obviously, have little or no impact on the main project. The situation with FOray is more complicated. I don't know whether it is Victor's intention to fork from HEAD and continue the development along the lines he has previously discussed, or to attempt to integrate HEAD and the maintenance branch in some way. In any case, what Victor is doing will closely parallel the HEAD development, and this, combined with the possibility of some financial support, has a great potential to de-stabilise FOP. I'm not saying this as a criticism of Victor, but as a bald statement of the reality. Many Apache projects seem to me to be wide open to this kind of de-stabilisation. Those projects with a large contingent of paid developers will not be affected; those with few of no paid developers (e.g. FOP) will be. I think the Board might better serve Apache by addressing this issue rather than some others on its current agenda. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: User configuration for hyphenation
J.Pietschmann wrote: Glen Mazza wrote: I believe the same logger reference would just be used with each thread instead, es, and this is exactly the problem. It is conceivable that different loggers might be used for different processors which run in concurrent threads. A static logger reference prohibits this. However, the logger naming is purely conventional (at least in 1.4 logging), so if the need for different logging in different threads arose, it could be accommodated by appending a thread-based suffix to the logger name. Or was there some other problem you had in mind here? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
More on font properties
Fop-dev font-devs, My reading of the Javadocs for both 1.4.2 and 1.3.1 has turned up some interesting questions. Since 1.3.1 (at least), java.awt.Font has defined constants for CENTER_BASELINE, HANGING_BASELINE and ROMAN_BASELINE. These correspond to the Central, Hanging and Alphabetic baselines of the Rec at 7.8.1 Fonts and Font Data, which includes: quote XSL assumes that the font tables will provide at least three font characteristics: an ascent, a descent and a set of baseline-tables. /quote The Rec actually aligns ideographic text on the Ideographic baseline, but this seems to have a fixed relationship to the Central. Does the baseline discussion in the Rec have any echo in FOP? Are baseline tables implemented? Mind you, I don't yet know whether the baseline constants from Java are actually used anywhere. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: More on font properties
Jeremias Maerki wrote: On 13.04.2004 14:47:02 Peter B. West wrote: My reading of the Javadocs for both 1.4.2 and 1.3.1 has turned up some interesting questions. Since 1.3.1 (at least), java.awt.Font has defined constants for CENTER_BASELINE, HANGING_BASELINE and ROMAN_BASELINE. These correspond to the Central, Hanging and Alphabetic baselines of the Rec at 7.8.1 Fonts and Font Data, which includes: quote XSL assumes that the font tables will provide at least three font characteristics: an ascent, a descent and a set of baseline-tables. /quote ... Does the baseline discussion in the Rec have any echo in FOP? Are baseline tables implemented? No idea and I don't think so. Up to date we are lucky to have non-ISO-8859-1 characters display at all. I think Keiron started working on BIDI, and Karen had quite some knowledge, too. But I don't think it got any farther than that. We've got the ascender, the descender, the X/Cap-height and that's the three values that determine the placement of characters right now. See FontMetrics.java. Mind you, I don't yet know whether the baseline constants from Java are actually used anywhere. Neither do I, but trusting Eclipse's reference search, the answer is: no, they aren't in use, not even in JDK 1.4. Jeremias, I dug around in the API docs a bit more and found that the BASELINE constants are used in both 1.3.1 and 1.4.*. See http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Font.html#getBaselineFor(char) http://java.sun.com/j2se/1.4.2/docs/api/java/awt/font/LineMetrics.html#getBaselineIndex() http://java.sun.com/j2se/1.4.2/docs/api/java/awt/font/LineMetrics.html#getBaselineOffsets() There are corresponding entries for 1.3.1. http://java.sun.com/j2se/1.3/docs/api/java/awt/Font.html#getBaselineFor(char) http://java.sun.com/j2se/1.3/docs/api/java/awt/font/LineMetrics.html#getBaselineIndex() http://java.sun.com/j2se/1.3/docs/api/java/awt/font/LineMetrics.html#getBaselineOffsets() Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
