Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Peter B. West
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

2005-03-09 Thread Peter B. West
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

2005-03-09 Thread Peter B. West
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

2005-03-09 Thread Peter B. West
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

2005-03-08 Thread Peter B. West
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?

2005-03-07 Thread Peter B. West
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?

2005-03-04 Thread Peter B. West
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

2005-02-23 Thread Peter B. West
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

2005-01-17 Thread Peter B. West
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

2005-01-17 Thread Peter B. West
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

2005-01-16 Thread Peter B. West
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

2005-01-14 Thread Peter B. West
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

2005-01-13 Thread Peter B. West
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

2005-01-05 Thread Peter B. West
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

2005-01-04 Thread Peter B. West
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

2004-12-31 Thread Peter B. West
Greetings from the future.  Happy New Year.  Welcome to 2005.
Peter


Re: Happy New Year

2004-12-31 Thread Peter B. West
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

2004-12-28 Thread Peter B. West
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

2004-12-27 Thread Peter B. West
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

2004-12-25 Thread Peter B. West
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!

2004-12-24 Thread Peter B. West
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.

2004-12-12 Thread Peter B. West
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.

2004-12-10 Thread Peter B. West
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.

2004-12-10 Thread Peter B. West
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.

2004-12-10 Thread Peter B. West
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()

2004-12-08 Thread Peter B. West
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()

2004-12-08 Thread Peter B. West
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!

2004-12-01 Thread Peter B. West
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?

2004-11-24 Thread Peter B. West
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))

2004-11-04 Thread Peter B. West
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

2004-11-02 Thread Peter B. West
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

2004-11-02 Thread Peter B. West
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

2004-10-28 Thread Peter B. West
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

2004-10-28 Thread Peter B. West
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

2004-10-28 Thread Peter B. West
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

2004-10-28 Thread Peter B. West
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

2004-10-22 Thread Peter B. West
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]]

2004-10-22 Thread Peter B. West
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

2004-10-20 Thread Peter B. West
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

2004-10-20 Thread Peter B. West
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.]

2004-10-16 Thread Peter B. West

 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.]

2004-10-16 Thread Peter B. West
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.]

2004-10-14 Thread Peter B. West
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

2004-10-07 Thread Peter B. West
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

2004-09-12 Thread Peter B. West
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

2004-08-17 Thread Peter B. West
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

2004-07-27 Thread Peter B. West
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

2004-07-25 Thread Peter B. West
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

2004-07-24 Thread Peter B. West
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

2004-07-24 Thread Peter B. West
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

2004-07-22 Thread Peter B. West
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

2004-07-22 Thread Peter B. West
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

2004-07-19 Thread Peter B. West
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

2004-07-11 Thread Peter B. West
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

2004-07-10 Thread Peter B. West
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

2004-07-09 Thread Peter B. West
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

2004-07-09 Thread Peter B. West
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

2004-07-08 Thread Peter B. West
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

2004-06-29 Thread Peter B. West
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

2004-06-29 Thread Peter B. West
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

2004-06-29 Thread Peter B. West
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?

2004-06-28 Thread Peter B. West
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

2004-06-25 Thread Peter B. West
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

2004-06-25 Thread Peter B. West
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....]

2004-06-25 Thread Peter B. West
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....

2004-06-25 Thread Peter B. West
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....

2004-06-25 Thread Peter B. West
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

2004-06-17 Thread Peter B. West
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

2004-06-17 Thread Peter B. West
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

2004-06-17 Thread Peter B. West
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

2004-06-12 Thread Peter B. West
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

2004-06-12 Thread Peter B. West
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

2004-06-12 Thread Peter B. West
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]

2004-06-11 Thread Peter B. West

 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

2004-06-11 Thread Peter B. West
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?

2004-06-10 Thread Peter B. West
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

2004-06-09 Thread Peter B. West
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

2004-06-08 Thread Peter B. West
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


Java text geometry

2004-06-08 Thread Peter B. West
Fellow fops,
This is to update you on what I am doing with alt-design layout.
The central Java text layout class is java.awt.font.TextLayout.  The 
following description is edited from the API.
quote
TextLayout is an immutable graphical representation of styled character 
data.

It provides the following capabilities:
* implicit bidirectional analysis and reordering, (1)
* cursor positioning and movement, including split cursors for 
mixed directional text,
* highlighting, including both logical and visual highlighting for 
mixed directional text,
* multiple baselines (roman, hanging, and centered), (2)
* hit testing,
* justification, (3)
* default font substitution, (4)
* metric information such as ascent, descent, and advance, (5) and
* rendering
/quote

The aspects of particular interest are numbered.
TextLayouts are graphical objects whose origin is at the intersection 
between the layout's baseline and its left edge.  This is irrespective 
of the text direction.  For the purposes of layout, then, the graphical 
boxes into which flows are laid out exist in an absolute t-b-l-r 
context, rather than a relative bpd-ipd one.  The upshot of this is that 
all layout can be performed using the absolute orientation, rather than 
the relative, and bidi text, e.g., will be have the correct orientation, 
even though horizontal alignment of line-areas will have to take account 
of the text direction.

Reference-orientation introduces new considerations, but not as far as 
the relationship between absolute and relative edges is concerned.  The 
Rec spells out that, 'reference-orientation is a rotation and does not 
influence the correspondence mapping.'  Rotation can be accommodated by 
applying an Affine Transform when mapping the content-rectangle of a 
reference-area into its allocation-rectangle.

The case of vertical writing modes is unclear.  Even though 
java.awt.ComponentOrientation discusses four orientations - LT 
(left2right, top2bottom, e.g. English), RT (right2left, top2bottom, e.g. 
Hebrew), TL (top2bottom, left2right, e.g. Mongolian) and TR (top2bottom, 
right2left, e.g. Japanese), and has isHorizontal() and isLeftToRight() 
methods, only LEFT_TO_RIGHT and RIGHT_TO_LEFT static fields are defined. 
 When a ComponentOrientation is created for Locale.JAPAN, it returns 
true for both methods in 1.4.2.  It remains to be seem whether vertical 
mode TextLayouts will have an origin at the intersection of the baseline 
and the top edge, which I would expect.

These notes are, as I said, to keep you in touch with what I am doing in 
alt-design, and also to run these ideas past you to see if I am missing 
anything.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Writing modes and Java

2004-05-31 Thread Peter B. West
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

2004-05-29 Thread Peter B. West
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

2004-05-25 Thread Peter B. West
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

2004-05-25 Thread Peter B. West
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

2004-05-25 Thread Peter B. West
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

2004-05-24 Thread Peter B. West
Victor Mote wrote:
Peter B. West wrote:

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 last time I checked, there was no way to get to the physical font file
through the awt interface. It is possible that java.awt.font.OpenType can
provide some or all of what is needed for TTF and OT fonts, but I don't know
of a way to handle Type1 embedding at all. This means that you cannot ever
embed the said font, unless you set up a parallel system (similar to the way
FOP handles things now) to find the physical file. Another issue is headless
environments. I once went down the path of trying to figure out how to
register fonts in a headless environment, and frankly don't remember what I
learned. It is probably possible.
I don't know; I'm new to Java font handling myself.  Another disclaimer; 
I haven't considered the issue of embedding.  That said, I don't see a 
way to get to a physical font.

There may come a time when the awt system is the way to go, but AFAICT, it
isn't here yet, but I'll be glad to be proven wrong. I don't say this to
discourage you -- if you know how to make it work, that will be a very good
thing. BTW, Hansuli Anderegg has been a frequent advocate of the awt system
for this work.
One important point here is that, even if awt font handling were the correct
*implementation* of font handling to use, there would still be, IMO anyway,
utility in hiding even that fact from the rest of FOP, certainly no harm.
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.

I am taking the next comment out of sequence from Peter's original post,
because it is fundamental to comments earlier in his post, which I will
address below:

Fonts are inherently renderer specific.  It may be that those 

No. Font *embedding* is renderer specific. AFAICT, everything else about the
font is the same.

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.

It is a non sequiter to say that layout needs only font metrics (which is
true), and therefore the logical home for font selection information is the
renderer.
One thing that may be confusing you is the distinction that awt makes
between java.awt.Font and java.awt.FontMetrics. There is only one
constructor for FontMetrics:
protected FontMetrics(Font font)
FontMetrics *seems* to have been bypassed in the latest font handling. 
The methods that are being used in the 2D tutorials focus on 
LineMetrics, i.e. the metrics of particular pieces of text.  LineMetrics 
can be obtained directly from the Font, the text concerned, and the 
FontRenderContext, which is based on the AffineTransform (if any), and 
whether the rendering is anti-aliased or uses fractional metrics.  The 
text concerned can be a String or a CharacterIterator, providing access 
to character attributes.  Also available directly from Font are 
java.awt.font.GlyphVectors and the layoutGlyphVector method, which does 
bi-directional layout.

In addition, in java.awt.font are TextAttribute, TextLayout, 
LineBreakMeasurer, TextMeasurer and GlyphMetrics.  LineMeasurer is of 
limited utility, because it only implements a default line break policy, 
but TextMeasurer allows much finer control.  GlyphMetrics seems to be 
the preferred direction for layout measurement, giving precise 
dimensions for glyphs in a particular piece of text, laid out in a 
particular FontRenderContext.

Therefore, at a *logical* level, there is a one-to-one relationship between
the two. At the physical file level there is also a strict one-to-one
relationship between the two, when the metrics are separated at all. There
is no need that I can see for FOP to treat the concepts of Font and
FontMetric as two different things. Once a font object is stored in the
FOTree that object should be able to return any metrics information about
that font.
I agree.

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

Re: Fonts

2004-05-24 Thread Peter B. West
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

2004-05-24 Thread Peter B. West
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

2004-05-24 Thread Peter B. West
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

2004-05-24 Thread Peter B. West
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

2004-05-23 Thread Peter B. West
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

2004-05-23 Thread Peter B. West
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

2004-05-19 Thread Peter B. West
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

2004-05-19 Thread Peter B. West
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

2004-05-19 Thread Peter B. West
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

2004-05-19 Thread Peter B. West
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

2004-05-19 Thread Peter B. West
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

2004-05-18 Thread Peter B. West

[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

2004-05-18 Thread Peter B. West
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

2004-05-17 Thread Peter B. West
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

2004-05-11 Thread Peter B. West
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


  1   2   3   4   5   6   7   8   >