RE: Got Plass' dissertation

2005-03-10 Thread Victor Mote
Jeremias Maerki wrote:

 I got my copy of Michael Plass' dissertation today. A cursory 
 overview shows that this document will provide some insight 
 on using Knuth element model for page breaking but it also 
 makes clear that we still have to come up with solutions for 
 certain tricky problems that he didn't have to deal with back 
 then. At any rate, the dissertation seems more helpful than 
 the two documents we found by Brüggemann-Klein, Klein and Wohlfeil.

Hi Jeremias:

I got my copy yesterday and spent some time in it as well. I wanted to weave
some thoughts about it into the thread from a few days ago that dealt with
this same topic. In that thread, you raised the same two issues that I have
been troubled about for page-breaking: 1) differing page IPDs, and 2)
side-floats.

WRT differing page IPDs, I think it is probably very acceptable in almost
every case to simply change the rules. IOW, If you want to use layout
strategy X, you must do so on a page-sequence-master that has all page IPDs
the same and that uses the same column-count. (Plass acknowledges that the
problem to be solved is two-dimensional, but specifically says that his
algorithm is one-dimensional.) Whether dealing with business forms
(invoices, purchase orders, etc.) or high-end book publishing (I have
experience with both), I cannot think of a use case for differing IPDs on
pages in the same page-sequence. If the goal is 100% standard compliance,
this isn't good enough. However, if the goal is to get some work done for a
client, and it doesn't hinder future 100% compliance, then this would be the
way I would address it.

Side-floats are another story. Plass addresses them by adding a new
primitive to the box/glue/penalty model, called insert (page 15). However,
I thought the following was pretty interesting as well, drawn from the last
paragraph of his dissertation:

There are other ways of incorporating approximations into the pagination
routine; for instance, inset figures could be handled satisfactorily by
doing the pagination as if they were full width figures with the same area
as the original figures; afterwards the paragraphs could be re-broken in
order to fit them around the figures. The optimizing line breaking algorithm
would be helpful in this regard, since it could break the text on the page
in such a way that it would come out to the right number of lines. Layout
artists traditionally use approximate copyfitting techniques to do such
tasks, so methods like this hold much promise.

So, if an insert requiring 4 square inches is required, and the IPD is six
inches, add 2/3 of an inch to the BPD of the block, do your copyfitting,
then come back and lay the block out properly later.

After thinking through all of these papers and ideas, I am more convinced
than ever of the utility of pluggable layout. But I guess you guys like
branches better :-)

Victor Mote



RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-03-08 Thread Victor Mote
Renaud Richardet wrote:

  1. FOray has factored the FOP font logic into a separate module, 
  cleaned it up significantly, and made some modest 
 improvements. A few 
  weeks ago, I aXSL-ized it as well, which means that it is 
 written to a 
  (theoretically) independent interface:
  
 http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-font/src/java/org
  /axsl/
  font/
  I think there is general support within FOP to implement the 
  FOray/aXSL font work in the FOP 1.0 code, but so far no one has 
  actually taken the time to do it. If you get into messing 
 with fonts 
  at all, I highly recommend that FOray be implemented before doing 
  anything else. I will be happy to support efforts to that end.
 
 For what I understand now, your approach sounds good to me. 
 But I'm missing some major pieces of the picture ATM to start 
 implementing your aXSL interface in FOP. Please let me come 
 back to you when I'll feel more comfortable with the font-mechanism.

Sure. The main thing I wanted to alert you about is that right now, AFAIK,
the HEAD code is pretty similar to the maintenance branch code and
integration *should be* relatively easy. If improvements are made to the
HEAD code, then issues of merging, etc. crop up that make integration
difficult. That is OK too -- I just want to make sure that if it is done
that way, it is done that way on purpose.

Please feel free to contact me offline if you have implementation questions.

Victor Mote



RE: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Victor Mote
Jeremias Maerki wrote:

 While looking for material on page breaking I found several 
 references to this document:
 
 http://wwwlib.umi.com/dissertations/fullcit/8124134
 
 Does anyone know if it's worth ordering and waiting for it? 
 The unfortunate thing is that they don't seem to have a PDF 
 version that I could download immediately for a reasonable fee.

Wow. This looks like it is very valuable. I have ordered it for my own use,
and I'll be glad to give you a book review when it arrives to help you
decide whether it is worthwhile for you or not.

I am especially interested in the summary's comment: For certain simple
badness functions, the pagination problem is NP-complete; Dealing with that
challenge is the likely tricky spot in all of this. My intuition has always
been that the page-breaking problem is much more complicated than the
line-breaking one, partly because lines must be laid out to even think about
page-breaking (and line lengths can change as they move around), partly
because you are effectively working with changes in two dimensions instead
of one, and partly because there seem to me to be a lot more variables in
the problem. I am hoping to find some insight into the detection and
workarounds for the NP-complete situations.

Note that Stanford is Knuth's school, the date year is the same as that of
Chapter 3 of Knuth's Digital Typography, and that the author is the
co-author of that article. It may be possible to infer the same information
from looking at the TeX source code. Also, another source of similar
information would be Volume I of Knuth's Computers and Typesetting, aka
The TeXbook. It is essentially a commentary on TeX, by Knuth. Chapter 15
is entitled How TeX Makes Lines into Pages.

You guys are way ahead of me in terms of thinking about how to implement
this stuff. As you know, my approach has been to leave this stuff for last,
preferring instead to solve the outer-layer problems first, and provide for
multiple implementations that can be improved in parallel. However, I have a
great interest in your efforts, and will be glad to help any way that I can.
And, FWIW, I think you are on the right general track, in this regard at
least.

Victor Mote



RE: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Victor Mote
Simon Pepping wrote:

 Note that The TeXbook is TeX's user guide. Yes, Knuth's users 
 are quite advanced. It was my first book in the direction of 
 computers, and one of the most inspirational I have read.
 
 The TeX program is described in 'TeX The Program'. That text 

Oops. You're right. That is volume 2 from the same Computers and
Typesetting series.

 set up all the tools. It is up to yourself to decide whether 
 knowing TeX's implementation is useful. It is a best-fit 
 algorithm. There is no look-ahead. For example, TeX is not 
 able to balance two facing pages (or two columns on a page, 
 which for TeX is the same). I guess that a dissertation like 
 that cited above contains much more information than 
 implemented in TeX.

I'm not sure. The general TeX page-breaking algorithm is discussed in the
paragraphs before Appendix A of Chapter 3 of Digital Typography. The
general box/glue/penalty model is used, but only the current page is
considered. So I think the difference between best-fit and total-fit (as
described here anyway) is the amount of look-ahead itself, not so much the
algorithm. This is why I thought Finn's (IIRC) idea of a variable look-ahead
makes sense. A look-ahead of zero pages is a best-fit, a look-ahead of all
pages is a total-fit. But the algorithm is the same.

Anyway, I agree that the paper is probably the best source, but wanted to
give Jeremias some options.

Victor Mote



RE: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Victor Mote
Victor Mote wrote:

 Oops. You're right. That is volume 2 from the same Computers 
 and Typesetting series.

Er, it is actually volume B.

Victor Mote



RE: page-breaking strategies and performance

2005-03-01 Thread Victor Mote
Jeremias Maerki wrote:

 processing time and additional memory requirements. This 
 leads me to the question if we shouldn't actually implement 
 two page-breaking strategies (in the end, not both right 
 now). For a speed-optimized algorithm, we could even think 
 about ignoring side-floats.
 
 Obviously, in this model we would have to make sure that we 
 use a common model for both strategies. For example, we still 
 have to make sure that the line layout gets information on 
 the available IPD on each line, but probably this will not be 
 a big problem to include later.

This is an excellent idea. It has from time to time gone under the moniker
LayoutStrategy or pluggable layout. To do it without duplicating everything
requires that the other pieces of the system be modularized, the concerns
separated so that they can be reused. The upside is tremendous and the cost
pays for itself in developer productivity.

Victor Mote



RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Victor Mote
 an issue here. I did 
 this implementation more for myself than anything. If there's 
 a better way to render .bmp (JAI?), let me know. Otherwise, I 
 could try to convince the author to donate the code in 
 conterpart of some fine chocolate :)

FOP 0.20.5 handles BMP images OK. Looking at the FOP trunk code right now,
there is a BmpImage class in package image and a BMPReader class in
image.analyzer, so I am not sure what you mean here.

Victor Mote



RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Victor Mote
Jeremias Maerki wrote:

 Thanks for bringing this up. I almost forgot.
 
 I'd be in favor of integrating Victor's improvements in this area.
 However, I'd also be inclined to gently nudge you, Victor, to 
 bring the font stuff back to Apache into the XML Graphics 
 Commons area once that's set up. But I wouldn't have a 
 problem to use your code from your SourceForge location for 
 the moment. We haven't talked, yet, what you'd think about that. :-)

Hmmm. This is certainly an Apache decision, not mine. If it works better for
you to have the code a part of an Apache project, you are certainly welcome
to do that. IMO, it would result in a lot of unnecessary duplication of
effort. I used to think that duplication of effort was the greatest evil to
be avoided, but my experience on FOP has expanded my horizons a bit --
pulling in opposite directions is worse. Still, duplication should be
avoided if possible.

My suggestion would be the following: 1) Write your font logic to the aXSL
interface and use FOray as the implementation of that interface. 2) As
improvements to font logic are needed, ask for them. I'll do my best to
accommodate them within FOray. 3) If 2 proves unsatisfactory, I will be
happy to consider adding some Apache people as committers on FOray
(actually, I'll be glad to do that anyway). 4) If 3 becomes unsatisfactory,
fork FOrayFont into an Apache project and start hacking away, or start a new
project that uses the aXSL interface. 5) If the aXSL interface is inadequate
and for any reason can't be changed, fork it and improve as necessary.

Such a scheme allows us to be optimistic that we will be able to work
together, but protects everybody in case we can't.

Victor Mote




RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Victor Mote
Jeremias Maerki wrote:

 I think you misunderstood. I wanted to suggest transferring (not
 copying/forking) these parts over to Apache with you as a 
 committer in the Commons part. That would make it mostly your 
 decision. I'm all against duplication of efforts. Actually, 
 it was the motivation for this post. At Apache you'd have a 
 bigger audience as well as a bigger chance of finding people 
 willing to help. And I don't see a big risk for disputes as 

I don't mean to be rude or insult anyone, but the help I found at Apache was
a net loss. Sure, there is some real help, but it was far outweighed by the
hindrances. There is something wrong either with me or the way the FOP
community works, maybe both. Of the 18 months that I spent working on FOP, I
consider the last 12 of it to have been utterly wasted. Worse, I probably
wasted other people's time along the way. There is a steady stream of FOP
users who want to contribute to the project who simply cannot find a way to
overcome the obstacles that the FOP committers place in front of them. The
rather thin constituency that allows me to continue working on open-source
publishing software would evaporate if I went down that path again. At the
risk of seeming coy or ungrateful (I hope I am neither) it really is not an
option for me. As for a bigger audience, I am not worried about that. If we
produce something worthwhile, people will find it.

 willing to help. And I don't see a big risk for disputes as 
 there were for the overall approach for FOP.

You may be right, but I have reason to doubt it. If what you say were true,
FOP would have done a 0.21 release in September that incorporated FOrayFont:
a very modest (but real) cost to the project, significant gains to both
users and the project, the fairly speedy removal of a whole class of support
issues, a test-bed for one actual 1.0 module, modest cleanup of the code
base, the opportunity to attract developers to work on a much simpler
discrete subsystem, elimination of the *immediate* need for a competing
product, etc. IMO, that should have been a slam-dunk, but wasn't. Here is a
huge disagreement that has nothing to do with system design at all. As with
many other FOP decisions, I am just baffled.

 It was just an idea in the hopes of bringing people back 
 together to work on things with little to no potential for 
 disagreements.

I think we can and should work together, but I see only downside potential
to making the relationship as tight as it once was. My philosophy makes
ample room for making mistakes ... once.

Victor Mote



RE: Renaming the AWT Renderer to Java2D Renderer

2005-02-23 Thread Victor Mote
Renaud Richardet wrote:

 Your note sounded hard to me. My apologies to you and the 
 other members of the team. In the future i'll use standard 
 English. Please do not take my writing style as a sign of 
 misrespect, as this was NOT my intention. This style is 
 pretty well accepted in Switzerland (in German, we have to 
 capitalize all Words, so this saves a lot of
 Typing) and i find it personally nicer.

I doubt that anyone, including Glen, was offended by your style. You did
nothing wrong, nothing worthy of a public censure. I will resist the strong
temptation to flame the antagonist and simply say that politics are at work
as much in open source projects as they are anywhere else. I hope you will
not be offended either by what passes for leadership in FOP, or the awkward
silence from the rest of the team. Your efforts are appreciated, and I doubt
that I am the only subscriber to this list who was embarrassed by the
rudeness with which you were treated here.

Victor Mote



RE: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Victor Mote
Renaud Richardet wrote:

 Victor,
 in [1] you talked about dealing with the positioning of areas 
 during the AreaTree building. could you point me to the 
 classes in FOray that handle that logic?

...

 [1] 
 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
l.apache.orgmsgNo=10534

Hi Renaud:

The main classes where you can see this logic are Area, AreaFixed, and
AreaFlexible. However some of the methods are overridden in subclasses, esp.
LineArea, since it is the pivot concept between BPD-stacking and
IPD-stacking Areas. See especially the methods that start with br (border
rectangle), pr (padding rectangle), cr (content rectangle), and rr
(render rectangle, a concept invented for dealing with adjustments to the
content rectangle for things like justification). See also the methods
setProgressionDimension, incrementProgressionDimension, setAnteriorSpace,
and incrementAnteriorSpace where the sizes of the area and its resolved
before or start space is stored.

I have to give you a bunch of caveats. There is still a bunch of the old
stuff in those classes that I haven't gotten around to removing yet. The
location computation stuff works reasonable well ATM, but a lot of the
supporting code has serious problems, so you will get NPEs, etc. with even
simple documents. This is a work in progress.

Also, I haven't implemented only some of the necessary writing-mode and
reference-orientation changes. I am kind of torn ATM between nailing this
down solidly and trying to get a usable release done.

From a speed standpoint, FOray's approach may be sub-optimal. Each Area
computes its location relative to its parent's. The philosophy behind it is
that I want to store stuff only once, not so much to save memory, but more
to reduce confusion about the proper place to go for the data, and
(importantly) to get layout to the place where it doesn't know or care about
the location, orientation, or writing-mode of an area, only its size. At
some point, we may find that it is beneficial to cache the intermediate
computations for performance. It is not important to me ATM.

The ViewCVS of the classes mentioned is here:
http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-areatree/src/java/or
g/foray/area/

Victor Mote



RE: border-before-width length-conditional

2005-02-21 Thread Victor Mote
Jeremias Maerki wrote:

 Am I right that for a table-cell in collapsing border model 
 the conditional part of a length-conditional (ex. in 
 border-before-width) has no effect (i.e. is ignored)?

That doesn't sound right. I just did a cursory review of the standard and
can't find any support for that. However, the standard has a way of humbling
me from time to time, so I may have missed it.

Victor Mote



RE: Page breaking [was: Markers added to the wrong page]

2005-02-08 Thread Victor Mote
Finn Bock wrote:

 Not at all. It is a rather trivial change to knuth to pick a 
 page break when there is N pages of lookahead.
 
 If we assume that finished page knuth element arrive one at 
 time to the KnuthPage algorithm, the main loop becomes:
 
 addKnuthElement(element) {
  if element.isBox():
  totalWidth += element.width
  else if element.isGlue():
  if (previous element is box):
  considerLegalBreak()
  totalWidth += element.width
  totalStretch += element.stretch
  totalShrink += element.shrink
  else if element.isPenalty():
  if element.penalty  INFINITE:
  considerLegalBreak()
  if activeList.startLine  currentPage + lookahead:
  // In the activeList, find the node with the best demerit.
  bestNode = findBestDemerit()
  // Remove all nodes in activeList which does not 
 have bestNode
  // in their parentage.
  clearActiveList(bestNode)
   makePageBreak(bestNode)
 
 Here it is only clearActiveList() which does not have a fast 
 implementation when using the usual implementation of 
 ActiveNode. It will require a scan over all the active node 
 and for each node a scan back thru the previous links to the 
 node at currentPage+1.
 
 clearActiveList(bestNode):
  for node in activeList:
  // jump back thru previous (node.page-currentPage) times.
  while i++  node.page - currentPage
  previous = node.previous
  if previous != bestNode:
  activeList.remove(node)
   
 
 The rest of the methods called are similar to the methods in 
 my knuth line breaking patch (which is quite similar the 
 current implementation).

Hmmm. I guess it depends on where the N in N pages of lookahead comes
from. If that can be set to include the entire page-sequence, then you can
call it a Knuth-style algorithm. Otherwise, I think you have something less,
which is OK for those who don't want the performance hit.

 My own insecurity comes from figuring out which penalty values and 
 demerit algorihtm to use to get keeps and orphans right.

Yes. Fortunately, the XSL-FO standard provides some guidance here, but I
agree that this part will be a challenge.

Good luck. I am glad to see you guys heading down this path. Let me know if
there is anything I can do to help.

Victor Mote



RE: Page breaking [was: Markers added to the wrong page]

2005-02-07 Thread Victor Mote
The Web Maestro wrote:

 I don't know how the spec deals with this, but I doubt the 
 spec cares which algorithm is used. That said, would it be a 
 good idea to determine which algorithm to use based on 
 something in userconfig.xml or something? If the Knuth system 
 is more 'expensive' in terms of resources, we could make 
 non-Knuth the default, and enable Knuth via a config file.

Hi Clay:

The good news is that this is an excellent idea. The bad news is that FOP's
determination to not even tolerate more than one algorithm is what drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, which
might explain the absence of responses (so far).

BTW, since it is relevant here, thanks for your kind comments last week in
another thread. You are ever the peacemaker, a very useful role. As long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are also.

To my perhaps still naive mind, layout consists of exactly two tasks: 1)
finding line-breaks within logical blocks (nested blocks consisting of a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style algorithm
is by definition a total-fit algorithm. The scope of such an algorithm for
the first task is the logical block itself. The scope of the second task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a good
idea) for item 2, requires the ability to see an entire page-sequence in the
AreaTree at one time. I am a little confused about whether FOP's design will
even allow that to happen right now. I understood both Keiron's and Finn's
design ideas (and Peter West's also) to be releasing pages from the AreaTree
long before a page-sequence was even completely parsed. However, I may have
misunderstood, especially Finn's, which I am especially fuzzy on.

I read somewhere that Peter Karow was going to try to implement a
Knuth-style algorithm for URW, and I have tried desperately and
unsuccessfully to get a copy of his book on the topic. If anybody knows that
status of that effort or how to find his out-of-print books, please let us
know.

The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. That may
be sub-optimal, but it is my best guess right now about a reasonable way to
proceed.

Victor Mote



RE: Page breaking [was: Markers added to the wrong page]

2005-02-07 Thread Victor Mote
The Web Maestro wrote:

 e-mail... I suspect there may be another 'side' to the 
 story--there  always is--and that there's may be other 
 contributing factors... but this helps me understand much 
 more than I understood before. Your explanation below also 

Yes, there is another side, and I respect that. The point is that the
differences are hard-wired at a pretty low-level (think silicon instead of
Java). I am constitutionally unable to make myself work on a project that
*can* be broken up into smaller pieces and isn't. Others appear to be
constitutionally unable to allow that to happen. Most can probably live with
it either way. OK, not every problem is solvable, and not every difference
is reconcilable. We go on. You guys pull east, I'll pull west, and as long
as we're pulling *different* wagons, we each have a shot at making some
progress.

 Might these links help:

I think those are the other books, but, to tell the truth, after looking
at the links, I can't tell. I'll have to go dig out my old notes to see
which book I was wanting. I'll check into it further. Thanks.

Victor Mote



RE: Start using *-position traits?

2005-02-04 Thread Victor Mote
Jeremias Maerki wrote:

 Chapter 4.2.2 Common Traits defines four traits 
 (top-position, bottom-position, left-position, 
 right-position) which describes the placement of areas within 
 the nearest ancestor reference-area (or the 
 page-viewport-area). We don't use these trait but recreate 
 the placement of individual areas in the renderer (actually 
 and effectively in each
 (!) renderer). I wondered a few times during the last month 
 if we should have the layout manager handle the calculation 
 of the coordinates. This has a few advantages:
 - All layout is really in the layout managers.
 - Each renderer really only paints the areas in the place it 
 is told to.
 
 The obvious disadvantage is the effort needed to write the 
 code that generates these traits in all layout managers.
 
 The reason I'm bringing this up now is my attempt to 
 implement table row backgrounds where I don't manage to place 
 the background areas in the right places due to placement 
 logic in the renderer(s). Of course, there are work-arounds 
 and I only have to fix AbstractRenderer in this case but it 
 doesn't feel right. There's already enough placement logic in 
 the PDFRenderer which needs to be duplicated in all other 
 renderers. I can also remember the synchronization effort 
 when I wrote the original PSRenderer.
 
 I think it would also simplify the renderers itself, making 
 it easier to develop a new one, if we started using 
 left-position and top-position traits. The other two may be 
 necessary as soon as there's more effort towards implementing 
 writing-modes.
 
 Keiron responded to a similar question in 2002:
 http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-dev
@xml.apache.orgby=threadfrom=214823
 
 I don't share his opinion on point 3 because whenever we have 
 a change in reference-orientation we also have a new 
 reference-area which establishes a new coordinate system. So 
 I don't think it will be complicated to calculate the right 
 coordinates. But I may be wrong.
 
 Opinions?

Hi Jeremias:

It is fascinating to me how many times you and I happen to be working on
exactly the same issue, as we are right now. FWIW, the FOray approach is as
follows: Areas do not store any location information at all. The only size
information stored is a progressionDimension value and a value for the
resolved anteriorSpace. This is enough information, however, for each Area
to compute and return to the Renderer where it should be rendered. Every
Area either is or has an ancestor area that knows intrinsically what its
location is just from its properties. Every Area knows its own IPD and BPD.
So by considering the progressionDimension and anteriorSpace (the resolved
value of space-before/after or space-start/end) of other Areas already
stacked in the containing Area, any Area knows its location.

Keiron is right that the computations are tricky for changes in
reference-orientation and writing-mode, but I think dealing with them in the
Area tree once is much easier than any other approach I can imagine. My code
currently has the various writing-modes handled correctly (I think), but
doesn't yet deal with changes in writing-mode or reference-orientation. The
main reason I haven't tackled that yet is that I am still trying to decide
how much of that work belongs in Area Tree and how much needs to be
considered Renderer-specific. 

With this scheme, Layout never has to worry about location, orientation, or
writing-mode, only sizes (IPD and BPD). Renderers don't have to compute any
of them either, they just ask each Area where it wants to be rendered.

In short, I think you are very much on the right track here. One caveat: I
don't have all of my stuff working yet, so there may be a gotcha that I
haven't thought of.

If these comments are not helpful, please let me know. I don't mean to
generate noise -- I just like to support good ideas when I see them.

Victor Mote



RE: block-containers with BPD set

2005-01-27 Thread Victor Mote
Jeremias Maerki wrote:

 Thanks to Victor and Andreas for helping me here, although 
 I'm still confused.
 
 On 27.01.2005 00:25:27 Victor Mote wrote:
  Andreas L. Delmelle wrote:
  
   Do you feel the contents of the block-container should 
 not be broken 
   up at all? (Hence the analogy to a fo:external-graphic?)
  
  No, sorry, I didn't mean to imply that. I think the contents can 
  (possibly, depending on the overflow constraints) be broken up, but 
  that the viewport cannot be. So the analogy with external-graphic 
  breaks down there. The similarity is in the fact that they (in this 
  case) have a fixed size and must move in their entirety.
 
 This seems to be contradicting. I don't see how the overflow 
 property would control such behaviour. Also, if you say that 
 they must move in their entiretly, how can the contents be 
 broken up? Or does they
 refer to something else than the contents?
 
I'll try to clarify what I mean. A distinction must be made between the
viewport area(s)that are created by the block-container, which I will call
the container areas, and the areas that are generated by the children of the
block-container (block-level FOs), which I will call the child areas. Each
viewport area is a fixed size in the scenario described. It cannot be split
between columns or pages. If there is not room for it in its entirety on
page n, it must be moved in its entirety to page n + 1. However the child
areas are free to flow between the container areas, just like they would
flow between the main-reference-areas on two pages. So a block inside the
block-container might have part of its contents in one container area and
part in a subsequent one.

The overflow property enters in because of the Issue that you mentioned
(1.1 Standard, Section 6.5.3): pThe overflow property applies to this
formatting object. There is a question of interpretation on whether the
fo:block-container generates more than one area when the
block-progression-dimension is fixed./p pThe change proposed here
requires the user to specify the repeat value for the overflow property
when they want multiple instances of the block-container rather than the
initial value for overflow./p

The default value for overflow is auto, which probably results in contents
being clipped for printed media (there being no opportunity for a
scroll-bar). But if the user sets the value to repeat, additional content
areas can be created to contain the overflowed content. If the overflow
settings are such that overflowed content has no place to go, then
conceptually it all stays in the one container area, and is clipped. So the
setting of the overflow value on the block-container directly affects
whether those contents might be split between two container areas or simply
clipped.

You are correct that they in my original post did not refer to the child
areas, but rather to the container areas. My apologies for the ambiguity.

  Yes. This seems most useful to me in cases where the viewport would 
  occupy most or all of the main-reference-area, as in the 
 case of the 
  report-turned-sideways example I gave earlier. Suppose you 
 have some 
  unknown quantity of 132-column output you want to show in landscape 
  mode. You can create a fixed-size block-container, tell it 
 to overflow 
  into other ones, add a break constraint at the end of 
 each page, and 
  you now get n pages of output.
 
 Well, this is a case where I'd rather use a separate 
 page-sequence with the reference orientation set on the 
 simple-page-master.

Fair enough. Here are some things to consider:
1. I think using a block-container gives you the *potential* option of
letting the viewports be out-of-line areas. So your content might read: See
Listing 1 fo:block-container ... /fo:block-container, where the effects
of this ... The content continues, but perhaps the next 3 pages are filled
with the block-container contents. I am not yet convinced that I fully grasp
all of the implications of the ordering issues, so it may be that this isn't
supported by the Standard.
2. What if the requirement is that 2 portrait pages be turned 90 degrees,
side-by-side, on the now landscape page? Depending on the amount of room on
the first page, and the parity of the number of such pages, you might end up
with an empty half-page. If your content needs to continue (as opposed to
looking like a new chapter), the repeating block-container looks like a good
option.

Victor Mote



RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Jeremias Maerki wrote:

 Given a block-container where the BPD is specified, are its 
 children subject to column/page breaking if the whole 
 block-container doesn't fit into the available area in BP 
 direction? If yes, how is the remaining space in BP direction 

My reading of the passage cited is that, while it may be possible for there
to be more than one immediate child viewport, each of the immediate child
viewports fits into exactly one rectangle on one page, i.e. it cannot be
broken into more than one piece. Now, if by children you are referring to
(for example) a block object that is inside the block-container, then yes,
that block could generated areas that are inside more than one of the
immediate child viewport(s). In other words, the contents of the
block-container could flow from one viewport area to another, but each
viewport area itself must remain in one piece.

So, the direct answer to your question is (I think) no. If the BP
constraints cannot be satisfied in the current column/page, the viewport
must be moved to a subsequent one. That may seem klunky, but the user can
prevent it by making the BPD a length-range.

 direction? If yes, how is the remaining space in BP direction 
 which is not taken up the BC's children to be handled?
 
 The quote you provided above probably point in the right 
 direction. But I guess my problem is that I haven't found the 
 part of the spec, yet, that establishes this constraint for 
 block-progression-dimension. I've searched the spec back and 
 forth and haven't found anything. After a lot of thinking I 
 believe it's chapter 4.3.2 Overconstrained 
 space-specifiers, but I don't understand how this explains 
 whether to do breaking inside the block-container or not.

AFAICT, space-specifiers aren't part of the question. In my mind
block-container is analogous to an external-graphic. You wouldn't split an
image into two pieces. If the user has said
block-progression-dimenension=6cm, he/she has deliberately placed a
constraint on the viewport. The default behavior is that there is no such
constraint, that the viewport expands and contracts as needed to contain the
contents.

The use-case for block-container may help also. Suppose you are rotating the
contents 90 degrees so that you can show, for example, a wide page in
landscape mode. You might want the contents to use the whole page, so
specifying the BPD/IPD allows you to insist upon that.

I'm not sure I am right about this, and don't mean to sound dogmatic. This
is just my understanding of the matter.

Victor Mote.



RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Andreas L. Delmelle wrote:

 In either case it seems to make little sense to speak of 
 'remaining space'
 as in 'the space not allocated by descendant FOs inside the 
 b-c', unless you mean the space remaining on the _page_ after 
 the first child viewport for the b-c is added. The sum of the 
 b-p-d of the two child viewports will be five units, period.

Just to be clear (not argumentative), I was saying something quite
different. For the example that Andreas has given, my understanding is that
there would only be one child viewport area, containing the entire contents
of both blocks, but that it would be pushed onto the following column/page.
Only if the contents didn't all fit into the first viewport would additional
ones be created (and then only if the overflow properties are set properly).
The user has dogmatically told us how big the viewport(s) should be.

Victor Mote



RE: block-containers with BPD set

2005-01-26 Thread Victor Mote
Andreas L. Delmelle wrote:

 Do you feel the contents of the block-container should not be 
 broken up at all? (Hence the analogy to a fo:external-graphic?)

No, sorry, I didn't mean to imply that. I think the contents can (possibly,
depending on the overflow constraints) be broken up, but that the viewport
cannot be. So the analogy with external-graphic breaks down there. The
similarity is in the fact that they (in this case) have a fixed size and
must move in their entirety.

 As an attempt to clarify:
 I wasn't 100% certain, but IIC, not breaking the 
 block-container between the two blocks would come down to 
 having default constraints for the keep-* properties (initial 
 value other than auto)
 
 Very rough interpretation of how I read it, for the block-container :
 - keep-with-previous=always (only in case one of its 
 children returns a reference-level-out-of-line area ~ 
 side-float|absolute) or auto (in all other cases)
 - a default of keep-together=auto
 
  The user has dogmatically told us how big the viewport(s) should be.
 
 More precisely:
 The user has dogmatically told us the constraints to which 
 all viewport-areas generated by the block-container are subject.
 Would this mean that _each_ generated viewport-area has to be 
 _that_ big?

Yes (if I am right). They can choose not to constrain it at all, or they can
constrain it flexibly with a length-range. The fact that they have rigidly
specified the value indicates that they want it to be that size.

 (more or less the effect the page-height property has on the 
 page-viewport-areas generated during formatting) In that 
 case, is it even conceivable to have more than one 
 viewport-area for a block-container with constrained bpd?

Yes. This seems most useful to me in cases where the viewport would occupy
most or all of the main-reference-area, as in the case of the
report-turned-sideways example I gave earlier. Suppose you have some unknown
quantity of 132-column output you want to show in landscape mode. You can
create a fixed-size block-container, tell it to overflow into other ones,
add a break constraint at the end of each page, and you now get n pages of
output.

 Or would it mean that _all_ of them taken together should be 
 _that_ big?

The previously-cited 1.1 item seems to indicate that the constraint applies
to each of the viewport areas individually as opposed to all of them in
total. However, I could misunderstand.

 Having no constraints on the keeps, and only the bpd 
 specified, it seems perfectly legal to break and interpret 
 the bpd constraint as a total that may be divided over 
 multiple viewport areas, but it may seem a bit tricky.

You may be right, but I can't think of a case where that would be useful.

AFAICT, keeps and space constraints would be left intact for the contents of
the block-container. So, if a decision has been made that an additional
viewport is needed to fit the contents, the keeps, breaks, and spaces would
be used to decide which content went to an anterior vp and which to a
posterior vp, just like in any page-break decision.

Victor Mote



RE: Layout dimension mechanism

2005-01-21 Thread Victor Mote
Jeremias Maerki wrote:

 I think there is something fundamentally wrong with the 
 layout dimension mechanism. I've found two problems, one 
 minor, one very bad:
 
 1. While implementing percentages for 
 background-position-horizontal and -vertical, I realized that 
 it wasn't so simple to base the calculation on a simple 
 value. The percentage base is actually the padding-rect-size 
 minus the intrinsic size of the background image. Of course, 
 this value could be set by each layout manager but it seems 
 awkward to have to do that everywhere. Instead, I can easily 
 calculate this in TraitSetter.addBackground(), provided the 
 BPD and IPD of each Area is properly set before calling 
 TraitSetter.addBackground(). That's currently not the case, 
 however. But it's probably a good idea to do that anyway.
 
 2. The above let me calculate the background image position 
 easily for block-containers. When I wanted to check the same 
 for the body region I found some bugs that I'm not yet 
 testing for. While trying to fix them I found a problem when 
 I specify width=height=100% on a block-container as the only 
 child of a flow. The BLOCK_IPD and BLOCK_BPD layout 
 dimensions were fetched from the Root which returned the page 
 size instead of the content-rect size of the current region 
 body area (which is wrong for documents with different page 
 sizes throughout the document).
 PageSequenceLayoutManager also sets the page size as 
 BLOCK_IPD/BPD on each Region (which is wrong, too). In 
 principle, the BLOCK_IPD/BPD should come from the currently 
 applicable Region if there's no parent block-level object.
 
 I'm beginning to think that the layout dimensions should be 
 held and provided by the layout managers instead of the 
 FObjs. To evaluate a percentage-enabled value the layout 
 manager would have to call
 getLength() with some kind of context object that allows it 
 to fetch the right base values for percentage calculations. I 
 haven't fully made up my mind about that and I'd like to hear 
 what you guys think about this problem.

You have hit on one of the many reasons that I think a modular approach is
so important, and why I think FOP is *still* not ready to even attempt to
rewrite layout, and why not binding the property values is useful (I am not
sure that it is required, but useful). The Foray approach to the issue is
that such a value is computed in the Area Tree. The FOTree computes what it
can, but in such cases, it needs a dimension passed to it in order to be
able to complete the computation. Any point in time that this dimension is
needed, the related Area has been created. The layout system calls
area.traitBackgroundPositionVertical(), which calls
getGeneratedBy().traitBackgroundPositionVertical and passes the needed
dimension(s) back to it.

I HTH. It probably seems like I am beating a dead horse. That is not my
intention. I just think it has to be really frustrating to try to write
layout code when your FOTree and AreaTree issues are not resolved. I admire
those who try, but ...

Victor Mote



RE: FOP code in FOray [WAS: Preview for a general XSL-FO processing API]

2005-01-17 Thread Victor Mote
Victor Mote wrote (on November 28, 2004):

 The code in the fop-maint branch is code that has not yet been peeled 
 off into a FOray module. All of it eventually will be. The case of the 
 app
 module, which will eventually contain the API that you are looking for 
 is in an especially bad state ATM. I renamed the CLI class Fop to 
 FOray and also moved it into the FOray apps package (it seemed 
 especially confusing to ask users to start Foray from either a class 
 or package with fop in its name). However, all of the other related 
 classes still live on the fop-maint side. So the main class you are 
 looking for is org.foray.app.FOray, but if you follow in a debugger, 
 you will quickly be over in org.apache.fop.apps.Starter, and most of 
 the rest of that package will look pretty similar to FOP's maintenance 
 branch. The reason for this state is that I want to make major changes 
 to that outer layer of the API, but it won't get done until I get a 
 bit further along in getting the FOTree peeled off. I hope that helps.
 
 If you try to use FOray ATM, you may get errors on properties, which 
 is also currently in an ugly state, half using the old scheme and half 
 using the new scheme. I am not aware of any actual errors ATM, but 
 there almost certainly are. My general advice would be to wait until I 
 have it in a beta quality state again, but the other option is just to 
 let me know if a bug is causing you problems.

Hi Jeremias:

I think this is ready for JAFOP now. I didn't want to take the time to
complete this yet, but, for reasons unrelated to this thread, I did, a
couple of weeks ago, complete the FOray Application API work. You should now
be able to follow what is going on there much better. Everything that was in
the fop-maint branch has been moved to a FOray module, so there is no longer
a need to download that branch to do a FOray build. And the jumping around
between FOP and FOray is totally eliminated now.

BTW, this means that FOray is now divided into 12 modules with what are IMO
the correct dependencies between each module. That doesn't mean that
everything is working right yet, just that those who are interested can see
how I think the big picture fits together. The APIs and inner workings of
Font and FOTree are substantially cleaned up as well. AreaTree and Pioneer
Layout still need much work, which is in progress ATM. You'll see ugly
output in spots as I work through them.

The documentation for the FOray API is here:
http://www.foray.org/module/app/index.html

By way of analogy, FOraySession is the old Driver class, and FOrayDocument
and FOrayTarget were broken out from the old StreamRenderer class.

You'll probably get around to adding FOray to JAFOP before I do, but I'll be
glad to help any way I can. Since I don't use any of these implementations
for embedded applications, I may very well need to add some options that
don't seem obvious to me ATM. And it is always probable that the
documentation needs more work. Your comments and criticisms are most
welcome.

Victor Mote



RE: Implementing text-decoration

2005-01-04 Thread Victor Mote
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.

HTH.

Victor Mote



FontServer cleanup (FOray)

2004-12-16 Thread Victor Mote
Hi Jeremias and any others interested:

I finally got around to cleaning up the static nature of the FOray
FontServer class. It now can be and must be instantiated, and I agree that
this is a cleaner approach.

One of the main reasons that I hung on to the static-ish stuff is that I
didn't want to tote the FontServer around everywhere that Fonts were needed.
To avoid this, the FontServer instance is encapsulated in the FontConsumer
implementation. The FontConsumer still (as before) needs to be available
anywhere that font services are needed. Within FOray, this is pretty easily
accomplished by caching it once at the top of the tree and using recursive
methods to get to it, so font-related services are pretty unobtrusive.

Victor Mote



RE: Large files.

2004-12-13 Thread Victor Mote
Finn Bock wrote:

 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?
 
 IOW the event based layout can work both of a normal 
 parent/children linked tree and a sequential tree.

Hmmm. I must have totally misunderstood your original point, which I think
you expressed much better in your second paragraph above. I certainly didn't
mean to argue against event-based layout, which, in general, I support, but
rather against the idea that an FOTree node can necessarily be laid out when
it is first encountered. And I think I understand now why you have done the
massive propagation of properties -- am I correct in understanding that you
are essentially flattening the tree so that inheritance must be captured
before that flattening takes place? Or are you simply making that an option
now?

  The bottom line is that, if you
  conceivably need to see both the beginning and end of the input 
  simultaneously (which we do),
 
 I can see a need for several passes over the same tree 
 fragment, but do we really need to see the beginning and the 
 end at the same time?
 
 The auto table example appears to need 2 or 3 sequential 
 passes over the table subtree (one to find the 
 minimum/maximum column width and one to do the actual 
 layout), but the layout process is still sequential.

Perhaps we have a semantical misunderstanding here. By see, I mean that we
know what is in it, and a multiple-pass solution can accomplish that. I'm
sure I acknowledged that as one of the two possibly ways that I could think
of to accomplish the end.

Victor Mote



RE: Large files.

2004-12-13 Thread Victor Mote
Simon Pepping wrote:

 The code you presented seems to be an algorithm implementing 
 an iterator over a tree. Because it maintains its state, it 
 can be stopped and resumed at will, provided you keep a 
 reference to it.

 If LMIter would have a reference to its parent LMIter, and 
 could return to it after having processed all the siblings, 
 it would realize such a construct. One could stop the 
 iteration, retain a reference to the active LMIter, and resume later.
 
 Not being dependent on the Java stack would make the 
 programming much more robust. One would have more freedom to 
 insert actions, without the fear to lose the iteration state 
 if one would not carefully return to the same function.
 
 Such a construct would be equally suitable to pull parsing. 
 The LMIter call to the LM method preLoadNext would request 
 more child fo nodes, which the parser would provide on this demand.
 
 On Mon, Dec 13, 2004 at 08:29:43AM -0700, Victor Mote wrote:
  Finn Bock wrote:
  
   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?
   
   IOW the event based layout can work both of a normal 
 parent/children 
   linked tree and a sequential tree.
  
  Hmmm. I must have totally misunderstood your original 
 point, which I 
  think you expressed much better in your second paragraph above. I 
  certainly didn't mean to argue against event-based layout, 
 which, in 
  general, I support, but rather against the idea that an FOTree node 
  can necessarily be laid out when it is first encountered. 
 And I think 
  I understand now why you have done the massive propagation of 
  properties -- am I correct in understanding that you are 
 essentially 
  flattening the tree so that inheritance must be captured 
 before that 
  flattening takes place? Or are you simply making that an option now?
 
 Do you want to traverse the FO tree, without relying on the 
 Java stack, and drive the layout process from there by firing 
 node events?

Hi Simon:

You responded to my last posting in this thread, but your questions seem to
be directed to Finn, so I will let him answer them. Please let me know if I
have misunderstood.

Victor Mote



RE: Large files.

2004-12-10 Thread Victor Mote
Peter B. West wrote:

 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.

Now that you mention it, I recall you saying something about a temporary
data structure (IIRC), to which I replied sounds like an FO Tree, to
which I never received a substantive reply. My apologies -- I didn't mean to
misrepresent Defoe.

I have some other comments on the table layout and look-ahead issues, but
I'll make them to you off-line, because I think the FOP folks don't want the
design conversations here.

My apologies for my part in starting this thread. Simon's original comment
could be interpreted in either a general or specific way, and I just wanted
to clarify that aspect of it. I didn't mean to start a debate at all.

Victor Mote


RE: Large files.

2004-12-09 Thread Victor Mote
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). 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.

Victor Mote



RE: Another problem with Marker.rebind()

2004-12-08 Thread Victor Mote
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 

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.
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), then the
solution may be as simple as using some redirects when static content is
involved. This depends, in turn, on late binding (really, no binding) of the
property values, which does not appear to be possible with the current FOP
design. 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.

Victor Mote



RE: Good news: Jeremias has been elected as an ASF member!

2004-12-01 Thread Victor Mote
Bertrand Delacretaz wrote:

 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.

Congratulations to Jeremias, the ASF, and FOP!

Victor Mote



FOP code in FOray [WAS: Preview for a general XSL-FO processing API]

2004-11-28 Thread Victor Mote
Jeremias Maerki wrote: 

 I finally downloaded the Foray code yesterday because I 
 thought it might be fun to write that implementation already. 
 I didn't invest a lot of time but I got confused about the 
 mixture of Foray and FOP code. Didn't really know where to 
 start. But that's another story. I should probably look 
 harder. Anyway, I got a renewed itch now to look at the PS 
 interpreter. :-)

The code in the fop-maint branch is code that has not yet been peeled off
into a FOray module. All of it eventually will be. The case of the app
module, which will eventually contain the API that you are looking for is in
an especially bad state ATM. I renamed the CLI class Fop to FOray and also
moved it into the FOray apps package (it seemed especially confusing to
ask users to start Foray from either a class or package with fop in its
name). However, all of the other related classes still live on the fop-maint
side. So the main class you are looking for is org.foray.app.FOray, but if
you follow in a debugger, you will quickly be over in
org.apache.fop.apps.Starter, and most of the rest of that package will look
pretty similar to FOP's maintenance branch. The reason for this state is
that I want to make major changes to that outer layer of the API, but it
won't get done until I get a bit further along in getting the FOTree peeled
off. I hope that helps.

If you try to use FOray ATM, you may get errors on properties, which is also
currently in an ugly state, half using the old scheme and half using the new
scheme. I am not aware of any actual errors ATM, but there almost certainly
are. My general advice would be to wait until I have it in a beta quality
state again, but the other option is just to let me know if a bug is causing
you problems.

Victor Mote



RE: Preview for a general XSL-FO processing API

2004-11-27 Thread Victor Mote
Jeremias Maerki wrote:

 I've talked about it before, so in case anybody is interested 
 I've uploaded the Javadocs [1] for a general XSL-FO 
 processing API I've been working on during the last few 
 weeks. It's basically my API proposal that is (or rather was) 
 on the Wiki. I've called it JAFOP (Java API for XSL-FO 
 processing) for now. But naming can change... The 
 implementations for FOP maintenance branch and FOP HEAD 
 already work for simple use cases. No fancy stuff, yet (no 
 events, no userconfig.xml...). 

...

 If there's enough interest I can put the source code for the 
 API plus implementations on my website (or to a SF project or 
 somewhere else).
 
 I believe this common API could be interesting in the 
 following months when FOP HEAD advances. It can be used to 
 easily switch implementations or during development/testing. 
 And I've got a few additional ideas. As time allows...
 
 It might also be interesting to have implementations for 
 Foray, Defoe, XEP and maybe even ol' JFOR. I hope the design 
 is flexible enough to accomodate all Java implementations.

Hi Jeremias:

I looked at the doc, and I think this is all pretty useful. I'd like to
spend some more time on it later, and I think I will probably write a FOray
implementation after I get 0.2 released. Here are some preliminary thoughts:

1. How do you anticipate deploying this? It looks like the user is aware of
which implementation he is using, and therefore knows or can find the
class(es) that implement the interface(s). So it looks like your org.xml.fo
 org.xml.fo.helper stuff would go in some vendor-neutral project, and the
implementations would simply be part of the vendor package. Does that sound
right?

2. One thing that I really like about your idea is that, if done properly,
the implementation classes almost become self-documenting tutorials on the
API for the specific implementation. If jafop exposes a general API for what
is needed to process an FO document, then the innards of the implementation
show how to use the API for the specific implementation.

3. There is more going on here than I anticipated. In org.xml.fo, there are
four interfaces that a vendor needs to implement. I am not sure what
FOPEventListener is supposed to do. Of the other three, it looks like two of
them exist to handle variations in input. I *think* that these could be
boiled down to just one interface, and that the input variations could be
handled with overloaded methods or some other way. However, I sure could be
missing something.

4. If you think aXSL is an appropriate home for the vendor-neutral pieces of
this, that would make some sense to me. As we have previously discussed,
jafop is a subset of what aXSL is supposed to eventually handle. Vendors
using the app or jafop or whatever part of aXSL would be free to ignore
the other parts of it, if and when they appear.

5. I know when I see the substring FOP in the vendor-neutral part of this
stuff, that it is being used in a vendor-neutral way. However, since the
general term FO Processor has already been taken by a specific
implementation, it may be good to find some variation, not only for
political reasons, but practical as well (cuts down on confusion). Maybe
something as simple as PFO, or maybe the aXSL name can help here.

I think you have done a good thing here.

Victor Mote



RE: Adding competing products to FOP Resources page

2004-11-22 Thread Victor Mote
Clay Leeds wrote:

 I'm contemplating adding the following products to the FOP Resources
 page:
 - FOray
 - Defoe
 
 ...while I'm at it, I might as well add:
 - RenderX - XEP
 - AntennaHouse - XSL Formatter

Thanks for doing that Clay. I think this will be good for FOP's users, and
it should be good for FOP too. Essentially FOray can be testing and
improving these modules and interfaces while FOP works on the layout. Kind
of a competitive cooperation, or something like that.

Victor Mote



RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-07 Thread Victor Mote
Andreas L. Delmelle wrote:

 Victor, IIC, Jeremias' concern is about the PDF lib in HEAD 
 containing substantial improvements over the code in the 
 maintenance branch. One aspect that springs to mind is WRT 
 encryption support --as I recall, maintenance still had some 
 problems with this, for instance, when using custom fonts...
 Jeremias once mentioned that, in order to make it work 
 properly, he had to make significant changes to the PDF-related code.

Yes, I am well aware that there are improvements to HEAD in several places,
and that FOray will be missing those for the moment. I fully intend to
eventually integrate the HEAD improvements into FOray, but 1) it is
non-trivial, 2) I have bigger issues ATM (still trying to get FOTree
isolated), and 3) I don't want to do much until I either have to, or until
FOP decides how it will proceed -- if FOP decides to start with FOray's
isolation work and upgrade to HEAD, then it might be a joint effort. If FOP
decides to isolate HEAD's PDF lib directly, and if they use a common
interface (like aXSL), then I shouldn't duplicate that effort in FOray, I
should just wait until FOP is done with that work and drop it into FOray. If
FOP doesn't want PDF isolated, or has no interest in using a common
interface, then I'm not part of the picture at all.

My main point to Jeremias is that none of this has anything to do with
building an interface that everyone can use, except that: 1) FOray already
has the interface at least partially designed by virtue of isolating the PDF
code, and 2) making an interface *before* starting isolation work is a big
help in that work.

Victor Mote



RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-05 Thread Victor Mote
Jeremias Maerki wrote:

 from the website I don't quite get the scope of the project. 
 That might have to be made clearer. Anyway, I didn't want to 

Yes, just as soon as it is totally clear to me :-) Right now, it boils down
to here are some things that I think could/should be shared, can anybody
think of anything else?

 talk about it just yet, because it's not ready, but recently 
 I started writing a JAXP-like API for XSL-FO processors (I 
 called in JAFOP for now). It basically implements the ideas 
 we came up with in the API discussion over a year ago. In the 
 next few months I will probably need to integrate several 
 different FO-processors and want to have a common API for all.
 Especially having a uniform API between FOP maintenance 
 branch and HEAD is important to me because I need to get FOP 
 0.20.5 set up for PDF output and I will most probably need 
 the RTF output of FOP HEAD quite soon (all in the same VM, of 
 course). Also, the fact that we got 4 OS-FO-processors 
 screams for a common API so they can be used interchangeably.

I think you are thinking API for the application as a whole. My vision for
aXSL goes quite a bit deeper than that, trying to get a common API for the
modules, IOW breaking the problem down into smaller pieces. My perfect world
right now would have me using FOrayFont with RenderX. (That is not to say
that FOrayFont is as good as RenderX's font handling -- it is not, yet
anyway. But it means that I can get where I need to go more quickly with
FOrayFont than I can with RenderX). Even if RenderX didn't subscribe to
aXSL, making FOray do so would seem to make it more usable to more people.
And it at least gives hope to someone writing a piece that it might be
pluggable with some other pieces.

There was a thread several weeks ago that had to do with how to standardize
extensions between the various applications, and Finn's work on Property
binding was an indirect influence here as well. However, the main thing that
started me down this path was thinking through the possibility of further
modularization within FOray. Right now, for example, FOrayFont is totally
independent of anything that looks like XSL-FO processing. But FOrayPDF is
highly dependent on FOrayFont as are layout, the renderers, etc. It seemed
like a desirable thing to pull out a layer of abstraction that lets FOrayPDF
work, for example, with any other conformant Font system, or vice versa.
Now, fonts and graphics are pretty easy. I can pull out an abstraction for
fonts that has three interfaces, one of which is already written (it may
need to get more complex later), and probably do a similar thing with
graphics. FOTree is much more complex, and AreaTree has complexities for a
different reason.

 Can it be that we had the same idea at the same time again? 
 :-) Of course, having standardized validation messages and 
 such goes a bit beyond what I imagined, but that's ok.

Actually, I don't envision standardized validation messages, although that
would be OK. (I suppose you could even handle the multi-lingual aspects of
that in a nice way.) I think that the original thread was dealing with how
the exceptions should be thrown, and that *would* be a good thing to
standardize, but different applications might want to handle them
differently.

I would characterize the two ideas as different, but very compatible, and
thinking along the same general lines. What you have done with JAFOP could
easily be a part of aXSL (or vice versa), and I would be glad to have you
participate, when the appropriate time comes.

Victor Mote



RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-05 Thread Victor Mote
Jeremias Maerki wrote:

 Ah, now I'm starting to see where this is going. I think this 
 something extremely difficult to do. To a certain degree it 

Agreed.

 sounds like my ideas/plans for the XML Graphics project, 
 namely to separate certain peripheral components (fonts, PDF 
 lib, Graphics2D implementations etc.) from FOP so efforts can 
 be pooled between projects where easily possible (i.e. 
 without major religious wars). For example, Peter is quite 
 interested in the Graphics2D implementations. But going to a 
 level of detail you hint at (at least that's my impression) 
 will prove really difficult. You know I'm all for 
 componentization, but you may have too high hopes here. But I 
 could be wrong. Don't spend too much time explaining this to 
 me. :-) We'll just see what happens. I will monitor what's 

The standards themselves do not need to be monolithic. So maybe one
implementation implements only aXSL-Font (I'm making this up as I go), while
another might implement all of them.

The idea is that one more axis of benefit is added into the product mix.
Assume that modularization is even possible, which is yet to be proved, at
least by any of the open-source implementations of which I am aware. Assume
also that, all other things being equal, it is a desirable trait, not just
for the developer, but for the end user. If these are both true (and I think
they are), a product that chooses *not* to implement it would presumably
want to have a really good reason for not doing so. Defoe's reason might be
superior performance (as I understand it), which is quite possible, and
FOP's might be a quicker time-to-market (as I understand it), also quite
possible, at least starting from today.

If *setting* a standard devolves into a religious war, we should probably
abandon the effort. However, I don't know that it needs to. When you think
about it an API for the FOTree, for example, the standard almost writes it
for you.

 going on. So, we're still going in the same general direction 
 although I'm still a bit concerned that you based your PDF 
 part on the maintenance branch code (that's still the case, 
 isn't it?).

FOrayPDF is based on the maintenance branch code, but I am not sure I
understand your point. I assume you are thinking of how to get a PDF-library
created in the new Graphics project? If I understand where you are headed,
you have to either duplicate in HEAD the work that I have done in isolating
it, or you have to duplicate the changes made since FOP forked itself. Since
it is in FOray's interest to have the better PDF library available, I might
do the latter -- it is just a matter of priorities  right now finishing the
modularization is more important (to me). And since PDF is a relatively
discrete part of the system, it may not be too hard to do. If you guys
decide to do the former, having the aXSL APIs in place would be a very
valuable tool in that process. I'll be glad to explain why when you are
ready to look at it, and perhaps I'll have something concrete (about the
abstractions :-) to show you by then as well. I'll be very happy to try to
coordinate this stuff so that we don't duplicate effort -- there has been
and will be too much of that as it is.

Victor Mote



aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))

2004-11-04 Thread Victor Mote
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 Mote



RE: AreaFactory patch

2004-11-03 Thread Victor Mote
Finn Bock wrote:

 I got some minor suggestions to the patch:
 
 - It should be strict typed: createBlock(..), createInline(..)
 - It should be complete so that all area creation was done through the
factory, not just the 3 areas that Tibor needs.

Yes.

Victor Mote



RE: AreaFactory patch

2004-11-03 Thread Victor Mote
Glen Mazza wrote:

 I've bought it due to my work with the apps package and 
 removing AddLMVisitor, and how reducing the complexity 
 allowed many other changes in other areas that weren't 
 previously apparent to occur.  I also think that many of your 
 later enhancements in properties wouldn't have become obvious 
 if you didn't first get us out of the XSLT-generated 
 properties classes.  Even I was able to implement some 
 (minor) property-related API changes as a result of your work 
 in getting rid of the autogenerated code.

I know better than to take this bait, but ...

1. The XSLT-generated stuff is a separate issue. Not relevant here at all.
2. It has already been pointed out that, if the Visitor stuff was so
terribly complex, there were other solutions that could be applied that
didn't sacrifice modularity. Also, it was never intended as a long-term
solution, but rather reflected the current state of the layout design,
which, after modularization, would have (or could have) changed.
3. Things should be made as simple as they can be, and no simpler. More
importantly, there are tradeoffs even within simplicity. Modularization is
one aspect of simplicity. It is true that modularization requires the use of
interfaces, which add some incremental complexity. But the benefits of
having good interfaces and clean separation of concerns reduce complexity
much more on a different axis. I have said before that I am glad that Xalan
is a separate module from FOP -- that was good thinking. I'm glad that FOP
doesn't have to compute disk sectors or lay out pixels on a page -- somebody
was smart enough to abstract out operating systems and printer drivers
instead.

Now, some on this list persist in the let's finish coding the project and
then we'll stop and design it line of argument. I have taken it as a
settled issue that this is FOP's policy, hence FOray. I won't work on a
project that takes that attitude. I unwittingly tried that for about 18
months, lost a year of my life and an incalculable amount of money in both
real and opportunity costs. FOP lost a good (IMO) developer and managed to
create for itself unnecessary and wasteful competition where none was really
needed. What a waste.

So here is a promising developer that shows up with an idea. It helps him
get his work done, and seems to make for a cleaner design (I haven't looked
at it closely, but I haven't heard anybody argue with this). You can tell
him (like you did me) we don't need no steeenking clean design. Or you can
learn a lesson and try to start developing relationships with the kind of
developers that you are going to need to finish this project. Makes no
difference to me. But, please, if you choose the former, send that promising
developer toward FOray -- I'm almost at the stage where I can drop in the
new layout system there. We'll find a place for good design ideas there.

Victor Mote



RE: AreaFactory patch

2004-11-03 Thread Victor Mote
Andreas L. Delmelle wrote:
 Not only that. The use-case he described doesn't seem at all 
 far-fetched.
 Imagine FOP/FOray/Defoe having an AWT renderer that displays 
 an editable XSL-FO in one window, the rendered result in the 
 other, and allows for updates/modifications made in the first 
 to be --as fast as reasonably
 possible-- reflected in the rendered version, without having 
 to render the whole --possibly very large-- document anew 
 every time. Those who are not at least a little curious about 
 this, may now leave :-)

Yes. You might be interested in:
http://www.foray.org/goals.html#big

Victor Mote



RE: Defoe

2004-10-29 Thread Victor Mote
Peter B. West wrote:

 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?

I actually spent some time on your blog yesterday, and I think it is
probably useful for the kind of work that you are doing. My work is much
more mundane, and, between commit logs and project documentation and
announcements, a blog would be pretty redundant for me (although the commit
log will be more useful when we are using Subversion). Probably the closest
thing to a blog that I have is:
http://www.foray.org/release.html

I haven't really craved the 5.0 features yet, but did finally decide a few
days ago to use 1.4 as a minimum, primarily to eliminate preprocessing
(developer productivity) and to use assert.

Victor Mote



RE: Defoe

2004-10-29 Thread Victor Mote
Clay Leeds wrote:

 I think it would be helpful for you both to include an 'examples' 
 section on your site to display the fruits of your labor (w 
 links to the FOs that generated them!).

That is a good idea. The FOray web site started out thinking of itself as an
extension of the FOP website (and therefore referring to it for basics like
example), and it still has that perspective. Changing that to a turnkey
operation is one of the reasons FOray 0.2 has been delayed.

Victor Mote



[DOC] font-variant

2004-10-28 Thread Victor Mote
Hi Clay:

I was looking at the compliance page on a totally unrelated topic, and
noticed that the property font-variant (Sec. 7.8.8) is listed as no.
When it is convenient, that should probably be changed to partial with
comments similar to the following:

1. True small-caps (glyph substitution) is not supported. However, faux
small-caps is supported, i.e. lower-case glyphs are shown as their
corresponding upper-case glyphs, but at a smaller point size.

2. [Workaround] For fonts that have true small-caps in a separate font,
true small-caps can be achieved through your stylesheet. Use a different
strongfont-family/strong to point to the true small-caps font instead of
using strongfont-variant/strong.

It may also be worth announcing the doc change on fop-user. Let me know if
you have any questions. Thanks.

Victor Mote



RE: [DOC] font-variant

2004-10-28 Thread Victor Mote
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 

...

 Actually, if you could help me a bit to figure out what 
 happened with the compliance page, that might help me 
 understand more about that page, and the system used to 
 output its rather complicated table.

First, I hope my comment wasn't considered a nag. I just wanted to pop that
documentation change off of my stack.

Second, the new web site is smokin' hot.

OK. The compliance page uses a different DTD than any of the other pages:
xml-fop/src/documentation/resources/schema/dtd/compliance-v10.dtd

One possibility to consider is changing it to the standard format. That is
probably possible, but you may have to give some things up to get it done.
My recollection is that I always decided it was worth it to use the
non-standard way. Also, the standard DTD may be better now than it was.

A different DTD means that it must use a different stylesheet also. This is
likely the crux of the problem. The process of telling Forrest/Cocoon about
the compliance stylesheet is probably broken. The easiest solution is
probably to ask on the Forrest user list. They were always extremely helpful
in solving these problems. When I was working with Forrest, it required a
decent understanding of Cocoon, but their newer versions might hide some of
that. Look in one of the sitemap files (sorry -- I don't remember which
one is the
current one):
xml-fop/src/documentation

In each you'll see a section entitled FOP Additions (line 295 in
sitemap.xmap, and line 257 in sitemap-0.5.xmap). That shows you the location
of the stylesheets as well (there is another entry later for the to-pdf
stylesheet). Find out where the equivalent sitemap for the new version is
and how to mimic the logic that is here.

That's about all I can think of to tell you. Good luck.

Victor Mote



RE: Defoe

2004-10-28 Thread Victor Mote
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?

Victor Mote



RE: Exception hierarchy.

2004-10-26 Thread Victor Mote
Andreas L. Delmelle wrote:

 What about:
 - LayoutException
 - AreaException
 - RenderException

FWIW, this is exactly where FOray is headed. You and Finn are on the right
track.

Victor Mote



RE: PS Interpreter

2004-10-07 Thread Victor Mote
Jeremias Maerki wrote:

 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.

Actually, FOray eliminated the intermediate font metric XML files several
months ago, and parses the TTF, PFM, PFA, and PFB files on-the-fly. I'll try
to add an AFM parser in the next few days, and then I think we'll have the
best of all worlds -- you can hand-tune an AFM file if you want to, but
otherwise, just use the files that ship with the font. We may have some
performance/memory issues that result from this, but I think the code is set
up to accommodate some configuration items after I start getting some
feedback about what people want.

BTW, I want to compliment the people that wrote the original font code.
There was really a large amount of good and useful code in there. I spent
several months refactoring it to make it cleaner and easier to use, but I
came out *way* ahead of starting over again. My current theory about
open-source development is that, because so many people work on it, it
evolves into something that is a bit convoluted. Every once in a while, you
need a refactoring cycle to clean it up (really to impose or reimpose a
design after-the-fact). My current theory also includes the idea that nobody
really wants to do that work, because it isn't very much fun, and because it
is hard to see an immediate benefit. Anyway, my compliments to Tore and
Jeremias and the many others who wrote the base code.

Victor Mote



PS Interpreter

2004-10-06 Thread Victor Mote
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.

The FOray font package is therefore now able to correctly gather the
FontBBox and StemV values for a PDF. (The ItalicAngle has also been elusive
-- it is actually in the PFM file under the name etmSlant. The FOray package
now parses and uses it as well.) I think this means that all of the elusive,
estimated pieces are now correctly computed using 1) either a PFA or PFB
file and 2) a PFM file.

This will also help in future subsetting work, and font embedding
enhancements (like converting ASCII hex fonts to binary to make the file
smaller).

Since the parsing takes some extra time and memory, I may need to provide
ways to cripple or partially cripple this process for users who don't want
to pay that much for the benefit.

An AFM parser is still needed, primarily so that users can conveniently
override values if they need to. But I think the backwards-compatible
ability to not require an AFM file is nice.

The PostScript parser itself is pretty rudimentary. After pulling the errors
and obvious non-operator items out of the list, there appear to be 352
operators for Level 2 compliance. I have only implemented 42 of them so far.
However, a lot of the brain-bending part of the design work is done, and I
think it should be a good starting place for other PostScript-related
projects, like EPS conversion. Here is the ViewCVS link to the
PSInterpreter:
http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-ps/src/java/org/fora
y/ps/PSInterpreter.java?view=markup

The other files are in the same directory.

I'll probably leave it alone until I need more from it, but I wanted to
update Jeremias and anyone else who is interested.

Victor Mote



[From fop-user] RE: problem in rendering PS image

2004-09-23 Thread Victor Mote
[Thread moved from fop-user]

Jeremias Maerki wrote:

 Note: Support for EPS graphics in PDF has been deprecated 
 with the latest specs.

When I saw this comment, I went looking for this in the PDF Reference, Third
Edition (for PDF 1.4) and Fourth Edition (for PDF 1.5), and couldn't find
it. Could you be more specific about who is doing the deprecation?

Reason: I am in the middle of writing a very rudimentary PS Interpreter for
FOray, for purposes of properly parsing the contents of Type1 font files.
There are easier ways to accomplish the immediate purpose, but one reason I
went to this level of trouble is that I *think* it may help us in embedding
EPS files in PDF. If EPS graphics are being deprecated within the PDF
standard itself, that is of great interest.

Victor Mote



RE: [From fop-user] RE: problem in rendering PS image

2004-09-23 Thread Victor Mote
Jeremias Maerki wrote:

 PDF Reference Fourth Edition Version 1.5:
 Chapter 4.7.1, page 296:
 Note: Since PDF 1.4 encompasses all of the Adobe imaging 
 model features of the PostScript language, there is no longer 
 any reason to use PostScript XObjects. This feature is likely 
 to be removed from PDF in a future version.
 
 Apparently it already is in reality, because Acrobat Reader 
 6.0.2 no longer passes EPS images to a PostScript printer, 
 while Acrobat Reader 5.x does. 

OK, I see what you mean, and I am intimately familiar with the citation.
Embedding EPS as an XObject is deprecated. However, using EPS as input for a
PDF document would not be deprecated by the above statement. Instead they
are suggesting that because there is a one-to-one relationship between the
capabilities, that any PostScript code (EPS or otherwise) should be
converted to the PDF equivalent. So, EPS input is not deprecated per se,
just embedding it as an XObject.

  Reason: I am in the middle of writing a very rudimentary PS 
  Interpreter for FOray, for purposes of properly parsing 
 the contents of Type1 font files.
  There are easier ways to accomplish the immediate purpose, but one 
  reason I went to this level of trouble is that I *think* it 
 may help 
  us in embedding EPS files in PDF. If EPS graphics are being 
 deprecated 
  within the PDF standard itself, that is of great interest.
 
 Interesting. You probably know from my various comments on 
 this list that I'm longing for such a beast under BSD-style 
 license. Having an interpreter is one thing, but making it 
 paint EPS files to a Graphics2D will be another challenge 
 altogether. But even if it only supported some basic Level 1 
 elements this would already be extremely helpful.

This is *very* much in a state of flux right now (I just started the
interpreter 2 days ago), but here is the plan: I have a PSSystemDict class
right now that houses the various PostScript operators (I have 4 of about
500 working ATM). I *think* that it ought be possible to make a subclass
that hijacks (overrides) the native meaning of the operators to transform
them into PDF operators instead. We'll see how it goes. You are right that
it is non-trivial.

By Graphics2D, do you mean java.awt.Graphics2D? I don't really intend to
build anything that will be using that directly, although subclasses could
do that if it were useful. (Also, I suppose that it might be useful as a
common intermediate format, but I haven't thought that far ahead). IOW, I
guess I am building something pretty abstract, not intended to actually
drive any hardware. (It is abstract in the PostScript sense, but not the
java sense). So a subclass would need to handle Path Construction and
Painting Operators and similar items. So, for example, the PostScript
operator curveto pops 6 items off of the stack and appends a Bézier cubic
section. My interpreter (I guess its really an emulator) will only pop the 6
items off of the stack (i.e. it merely pretends to do the actual drawing).
But one subclass could use java.awt tools to draw something on the screen,
and another subclass could write a PDF c operator instead (I think -- they
look similar at first glance anyway). I think that should be a pretty good
way to proceed, but am interested in any comments.

Victor Mote



RE: DO NOT REPLY [Bug 31213] - [PATCH] AFP Renderer

2004-09-17 Thread Victor Mote
Pete Townsend wrote: 

 I've had some interest in the renderer, in fact some 
 enhancement requests!
 The renderer currently supports raster fonts (these tend to 
 be the most widely used) however I have a request to add 
 outline font capability, which should be straight forward.
 
 Rather than keep adding files to the patch, I'll create a 
 project on SourceForge. I'll use this to add enhancements and 
 also migrate the code to 1.0 when a more stable build is available.

You are welcome to create a project on SourceForge, but one of the purposes
of FOray is to provide a home for these things, if possible. I haven't had a
chance to look at your patch, but it interests me, especially since I am
focusing on font work ATM, and am interested to know whether the approach I
have taken will be flexible enough to deal with the AFP fonts. The short
answer is that I intend to use AFM files to provide font metrics for
raster/bitmap fonts, just to limit the number of parsers that we have to
have. However, if you already have another scheme working, I'll be glad to
see how we can make them fit.
www.foray.org

If that helps you at all, please let me know (off-list), and I'll take a
look at your code and see if we can find a way to work together. The
splinters are sometimes necessary, but the fewer of them we have, the
better. I apologize that I haven't had time to look at your patch already.

Victor Mote



RE: [Proposal] I volunteer to help with 0.20.6

2004-09-10 Thread Victor Mote
Anton Tagunov wrote:

 Perhaps Victor and/or some other patch authors would assist.

I wish I could help you, but I am blocked from development on that branch as
well.

Victor Mote



RE: foray integration

2004-09-08 Thread Victor Mote
Victor Mote wrote:

 Does anyone else wish to take up this project? It would seem 

...

 Whether through FOP or FOray, my goal is to get a general 
 release completed before the end of September, so please let 
 me know whether FOP wants to be part of it.

I conclude from the silence that FOP does *not* wish to be part of this, so
FOray will proceed on its own. This puts us in the regrettable and awkward
position of being competitors for now. I highlight this only because I have
previously disclaimed any such intention, and do not wish it to be so now.
However, it is probably not a big deal -- there are 10 of you, one of me,
and you have a three year head start.

I do have one ethical dilemma that I need to throw back to the FOP
developers, regarding FOP Bugzilla issues that have been addressed in FOray.
For example, I just completed the work to get the ToUnicode CMap written in
PDF output for CID fonts, which is Bugzilla entry #5335:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5335
I am tempted to make a note in the Bugzilla entry (but not to close the
issue), so that those who are interested will know that they can get the
issue fixed through FOray. However, since we are competitors, that might be
construed by you as plowing in your field, which is not my intent. If any
committer objects (within the next few days), I will refrain from making any
such entries. Otherwise, it seems like useful information, not only for FOP
users, but also for FOP developers who may wish to use the FOray solution as
a reference.

Best wishes to all of you.

Victor Mote



RE: foray integration

2004-09-08 Thread Victor Mote
Jeremias Maerki wrote:

 silence from my part is simply because I don't have time. 
 It's not that I'm not interested. I'm fighting on too many 
 fronts and have to prioritize. Your first mail in this thread 
 is still marked unread in my mail folder so I keep it on the 
 todo list.

I understand the time and priority issues all too well. The flip side of
this is that my time is worth something too (really), and my priorities are
important (at least to me). No one is more surprised or sorry than I that we
have been unable to find a way to work together. It seems to be impossible.
But I have said too much on this subject already. 

 What I hope is that you will continue to inform us of any 
 important developments on your side, that you also continue 

I don't mind doing this if there are no objections to it. I have no wish to
intrude or distract.

 to keep an eye on the upcoming XML Graphics project (when 
 it's finally looked at by the Board).

To be honest, I must have missed some of the key parts of the conversation
surrounding that project, and I don't really understand what is its purpose,
except that it seems to be an attempt to factor out some code that is common
to both FOP and Batik. If FOray's work is helpful along those lines, I'm
glad for it, and I'll help in any reasonable way that I can.

 I'll try to monitor what goes on in your project. Let's just 
 not drift apart to far that we can't converge again if, one 
 day, we see a possibility to join forces again.

FOP and FOray seem to have radically different and incompatible principles,
so convergence will probably depend on one or both of us changing
principles. Out of the 18 months I worked on FOP, the most productive half
of it was entirely wasted, and I have no intention of making that mistake
again. I've gotten 10 times as much productive work done in the last four
months as I did in my entire time working on FOP, and I'm having 100 times
as much fun. It's a little hard to imagine what might induce me to give that
up. Nevertheless, I'll watch with you to see if that possibility presents
itself.

Victor Mote



pdf filter configuration

2004-09-02 Thread Victor Mote
Background posts:

http://marc.theaimsgroup.com/?l=fop-devm=107844102423248w=2

http://marc.theaimsgroup.com/?l=fop-userm=108239654802077w=2

FWIW, as I set about to change this in foray, I realized that the filters
can be disabled by simply passing an empty set through the configuration.
For example:

  entry role=pdf
keystream-filter-list/key
list
/list
  /entry

If you completely remove the entire entry, you will get the effect mentioned
by Joerg, but the above will create a List with no entries that will be
used.

Another option:

  entry role=pdf
keystream-filter-list/key
value/value   !-- This line can be omitted --
  /entry

The following will yield a warning, but still give the desired effect:

  entry role=pdf
keystream-filter-list/key
valuenull/value
  /entry

This might be worth documenting for your end users.

This is also relevant to the testing scheme that Joerg put together a long
time ago. If unencoded files are used for the regression testing, then it
becomes more practical to diff them for debugging.

Victor Mote



foray integration

2004-09-01 Thread Victor Mote
FOP Devs:

I checked in with Chris Bowditch recently to see how his foray work was
coming, and he indicated that he has not had, and probably will not have in
the near future, enough time to complete the evaluation and make a
recommendation to you.

Does anyone else wish to take up this project? It would seem to me to
involve the following:
1. Determine whether the idea of FOP and foray working together is a
workable idea from FOP's standpoint. If not, stop.
2. Do some alpha testing of documents to see whether foray works.
3. Consider whether the API is suitable, and likely to be robust enough for
future expansion.
4. Determine whether FOP developers will do a 0.21 release out of
maintenance branch code. If not, skip to step 7.
5. Apply the fop-maint piece of foray as a large patch to the maintenance
branch.
6. Start into a release cycle.
7. Consider applying the foray API to FOP's trunk.

I think most of these should be pretty trivial except #7.

foray's current status is here:
http://www.foray.org/release.html

Whether through FOP or FOray, my goal is to get a general release completed
before the end of September, so please let me know whether FOP wants to be
part of it.

BTW, if you already have a foray sandbox, you might want to get a new one.
We recently acquired the foray.org domain, and I just moved everything on
the trunk from com.outfitr to org.foray. The 0.1 branch still exists, but I
don't see any point in using it for anything -- if someone wants to pick
this up, I'll start a 0.2 branch.

Victor Mote



RE: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-01 Thread Victor Mote
Glen Mazza wrote:

 While I'm implementing the validateChildNode() methods, I 
 would also like to work on removing the AddLMVisitor visitor 
 pattern[1], and revert to our previous method of having the 
 FO's themselves setup the LayoutManagers via 
 addLayoutManager().  (See here [2][3][4] for examples of the 
 previous way of a year
 ago.)  
 
 I believe this change will help make the fundamental 
 relations between the AreaTreeHandler, the formatting 
 objects, and the layout managers a bit easier to see, and 
 will hopefully lead to making layout less complex.
  (Architecturally, I'm also not too pleased with the large 
 amount of FO- and LM-specific business logic that 
 AddLMVisitor ends up needing to retain.)
 
 We haven't had any demand yet for the visitor pattern, and we 
 can always place it in later if needed after the FO/Layout 
 business logic has been better determined.  Any objections?

-0.

I'm sorry you asked (again), but since you did, of course I object. The 0
is because I am not a FOP stakeholder, but the - is because I am a Friend
of FOP. In exchange for making layout a bit easier you will be putting
layout logic in the FO Tree. How can it possibly lead to making layout less
complex? Nor do I see either the large amount of FO- and LM-specific
business logic that AddLMVisitor ends up needing to retain or why this
would be important. Maybe I am missing something here, but when you have no
presentation layer and no database, isn't pretty much everything business
logic? I guess a case can be made that the presentation layer is the area
tree and the data layer is the FOTree. That would make the layout engine the
business logic. If that is true, then you are getting ready to take the
business logic that is now in layout (where it belongs) and moving it back
to the FOTree. Maybe you could start by telling us how someone who insists
on a monolithic design even cares where business logic resides.

Now, in all honesty, there are other ways (besides the Visitor pattern) to
obtain the separation I was seeking. If I had known that the Visitor pattern
would be received as being monstrously complex, I think I would have chosen
another option, and I have no objection to changing to one of those now.

However, this is well-fought territory, and I have no further interest in
its outcome. I mention it only to point out the *real* issue in case any
real FOP stakeholders are interested. It takes a special kind of logic to
deliberately set out to make something less flexible than it was, to reduce
the number of options available. However, that is the FOP company line, and
I am the one who is out of step with it. FOP's development strategy appears
to continue to be wholly staked on the imminent successful release of the
new layout system. Anything that is done to reduce the options to only that
one must result in the maximum resources being bent toward that goal, right?
Is anyone familiar with the economic concept of Unintended Consequences?

I don't mean for this to be a rant, nor do I want it to slow anyone down. I
just want to make very sure that no one thinks I agree with this stuff,
especially when no convincing case has ever been put forth that it is a Good
Thing.

Victor Mote



RE: Switch from AddLMVisitor to FObj.addLayoutManager()

2004-08-01 Thread Victor Mote
J.Pietschmann wrote:

 Well, the real stakeholders (aka users) are probably more 
 interested in working footnotes, or multi-column layout.

I don't understand. More interested in working footnotes or multi-column
layout than what? Is removing AddLMVisitor an advancement in getting
footnotes or multi-column layout working better? Are you reminding us of
your neutrality on modularity? Or are you saying that this kind of question
is irrelevant? Please let me remind you that I was responding to a direct
question.

Victor Mote



RE: FOray 0.1 release

2004-07-19 Thread Victor Mote
Jeremias Maerki wrote:

 I'm simply thinking that adding statics is a lot easier than 
 removing them again. I usually create non-static classes and 
 create singletons around them if necessary or convenient. 
 That's basically it.
 
  One of the main purposes of
  FontServer was to share as much of the Font overhead as possible 
  between documents in a heavy server environment, while 
 keeping a light 
  footprint in the code. I actually tried to write it in a non-static 
  way (with you in
  mind) in the beginning, but it just ended up being silly, 
 at least for 
  the purposes that it is currently designed for.
 
 Of course, it makes sense to take the easy way to get quick results.
 I'm just thinking about the long run.

I didn't do it for the quick results, but for the lighter, cleaner effect in
the client application. Consider the pro-forma FontServer static method
someMethod(). Right now, using such a method is simply
FontServer.someMethod(). If I convert FontServer to a singleton, I see only
two choices:
1. Create a static method getInstance() to return the singleton. To use
someMethod(), I now need: FontServer.getInstance().someMethod().
2. Cache the FontServer instance somewhere in the application client and
pass it around. To use someMethod(), I now need:
someObject.getFontServer().someMethod().

The only reason I can think of to use a Singleton instead of statics is that
I might want to change my mind later  allow multiple instances. Since I
have been unable to find even a potential use case for multiple instances
that isn't covered by better client configuration, I didn't see the need for
the extra complexity. However, I am not really opposed to using a singleton,
and if it will make folks more comfortable, I'll reimplement it that way.
BTW, I was under the impression that you disliked GoF singletons as much as
statics. Are you OK with one here?

  Second, I *know* that, while in many ways HEAD is superior to the 
  maintenance branch, there are many specific instances where the 
  maintenance branch is superior to HEAD. I also know that 
 there is no 
  convenient list of such items. I have to choose between the 
 two evils 
  of 1) losing benefit(s) in the old code, and 2) losing 
 benefit(s) in 
  the new code. Of the two, I prefer the latter. The user is 
 not going 
  to be happy if I remove his wheels while installing the new, more 
  powerful engine. Better IMO for us to upgrade the engine in 
 a manner 
  that ensures that the wheels stay on. FOP is kind of into 
 the chasm thing, and FOray is definitely not.
 
 Right, but would you reconsider (in the long run) if we 
 worked towards seperately released components that could be 
 stabilized and shared between the different implementations? 
 All in the spirit of avoiding duplicate effort where this is possible?

I understand you to be asking whether I want to create components that can
be used by both the maintenance branch and HEAD. The answer is an emphatic
YES. And I want all of the features that are in HEAD in those components.
The only thing I meant to disagree with was the suggested approach of
starting with HEAD as the baseline. IMO the correct approach is to start
with the maintenance branch as the baseline and try to add in the code that
has been added to HEAD as we are able to identify it and port it. Neither
approach is ideal.

If I understood the above correctly, then you and I may be in pretty close
agreement on this whole approach. And, if you extend it a bit to other parts
of FOP, you can see where I was headed with the isolation of FOTree,
AreaTree, etc. It should be possible to factor everything out of FOP until
you are left with layout, which could be / should be / would be the only
difference between the maintenance branch and HEAD. Add in the concept of
LayoutStrategy, and you have everything back in one unified line of
development.

  and we can
  reconcile them. Ideally we want to get to the place where both 
  branches are using the same code. I *think* that is pretty easy for 
  Fonts and Graphics, but, as you say, probably not as easy 
 for PDF, and probably PostScript too.
 
 If it's possible for fonts then I'm sure it's possible for PDF and PS.

My perception is that *not* many features have been added to fonts and
graphics in HEAD, but that many have been for PDF and (possibly) PS. So my
thinking is that if we missed a thing or two in fonts and graphics, we'll
just deal with it as it comes. But with PDF and PS, we run the risk of
losing some large chunks of utility if we don't have either 1) someone
familiar with the changes guide the porting, or 2) someone go through some
detailed diff work to try to ferret out the changes. I just want to make
sure that my insistence in starting with the maintenance branch code instead
of HEAD isn't perceived as underestimating the difficulty in that approach.
It is ugly -- I just think it is less ugly than the alternatives.

Victor Mote



RE: FOray 0.1 release

2004-07-19 Thread Victor Mote
Chris, Jeremias, and anyone else looking at FOray code:

I have created the following branch in FOray's CVS that you will want to use
for your evaluation:
rel_0_1_branch

I have started some other changes in the root that should probably be
evaluated separately.

I apologize for the inconvenience. I really should have done this from the
start.

Victor Mote



RE: FOray 0.1 release

2004-07-16 Thread Victor Mote
Jeremias Maerki wrote:

 Making these parts into separate components is in line with 
 what I have in mind when can talk about a shared repository 
 between Batik and FOP. I hope I can take a good look into 

Good. I think it has potential to be useful to many applications.

 what you did later. From a quick look, however, I wasn't very 
 pleased that you propose to use a lot of statics in the 
 FontServer. I would prefer to have the possibility to 
 define multiple configurations in a heavy server environment 
 without having to go through the pains to separate multiple 
 environments using classloader magic. The system fonts are ok 
 like this, of course, but not the user-defined. Just my opinion.

I knew this would be controversial, and I'll be glad to consider changes.
The use case that you mentioned will, I think, be handled by some of the
other planned changes to configuration that are in the works. These changes
will be more client-centered than server-centered. So, rather than having
multiple servers configured different ways, each client will tell the server
more about what it wants, and the server will react based on this. However,
I may not see all of what you are thinking about here. If you can be more
specific, I'll think through this some more. One of the main purposes of
FontServer was to share as much of the Font overhead as possible between
documents in a heavy server environment, while keeping a light footprint in
the code. I actually tried to write it in a non-static way (with you in
mind) in the beginning, but it just ended up being silly, at least for the
purposes that it is currently designed for.

 Concerning the PDF library, I suggest you start from the PDF 
 lib in CVS HEAD instead of using the maintenance branch, even 
 if it means that the API may be a bit different. I've 
 invested a considerable amount of time to make the whole 
 thing better. Things such as encryption are much more cleanly solved.

First, in relation to FOP 0.20.5 (approximately FOray's starting place), the
changes that you are talking about are improvements, and I don't want to be
introducing changes or improvements yet. The goal here is really to make
sure nothing is broken. Then we can start making improvements, releasing
them, and getting user feedback.

Second, I *know* that, while in many ways HEAD is superior to the
maintenance branch, there are many specific instances where the maintenance
branch is superior to HEAD. I also know that there is no convenient list of
such items. I have to choose between the two evils of 1) losing benefit(s)
in the old code, and 2) losing benefit(s) in the new code. Of the two, I
prefer the latter. The user is not going to be happy if I remove his wheels
while installing the new, more powerful engine. Better IMO for us to upgrade
the engine in a manner that ensures that the wheels stay on. FOP is kind of
into the chasm thing, and FOray is definitely not.

Third, what you suggest is much easier said than done. I have made a note to
specifically check the encryption stuff when I get a chance. I suppose that
we can either diff the code (probably only useful to those who wrote it) or
use missing feature hunt. IOW, if we get to the place where we are
releasing code again, then, when issues come up on fop-user, hopefully you
or someone else will say I already fixed that in HEAD, and we can
reconcile them. Ideally we want to get to the place where both branches are
using the same code. I *think* that is pretty easy for Fonts and Graphics,
but, as you say, probably not as easy for PDF, and probably PostScript too.

Victor Mote



FOray 0.1 release

2004-07-13 Thread Victor Mote
FOP Devs:

I am pleased to announce the release of FOray 0.1 alpha 1. This release is
only useful to FOP developers. Some useful information about the release can
be found in these places:
http://foray.sourceforge.net/module/font/index.html
http://foray.sourceforge.net/module/font/release.html
Since it is developers-only, I have not prepared any downloadable packages.
You will need to use CVS to get the code. This is available here:
http://sourceforge.net/cvs/?group_id=109663

Probably the most efficient way to proceed is for Chris to do the initial
evaluation work. I can support him off-line, and probably will need to add
some doc as a result of his work. Then any others who wish to look at it
will have an easier time.

To cleanly get Fonts isolated, I had to isolate PDF, and to isolate PDF, I
had to isolate Graphics. So there are actually three FOray modules at the
moment (plus Common).

Please remember that this release is a no-feature release, but is intended
to address architectural issues only. The main purposes of the release are
1) to try to find out whether anything has broken, and 2) to get comments on
the general design.

Implied within FOray itself is a desire on my part to start getting code
released again. I realize that there are several views of how best to get
that done, and that FOray might be viewed as a distraction by some. If that
is the prevailing view, and FOP has no desire to release this code under any
circumstances, then you can save Chris a lot of trouble by reaffirming the
status quo now. This will put the burden on FOray to start releasing
essentially a competing product, which I am not eager to do. (This may
happen eventually anyway if I have time to pursue the modular design that I
think is important, but it is just as likely that a FOP 1.0 release will
make such an effort unnecessary). As a friend of FOP I have opinions on
what you should do, but my role here is different, and I will try to remain
neutral, providing information when needed. I'm really just a guy trying to
get some work done -- if it helps you, good; if not, that is OK too.

Please let me know if there is anything I can do to help.

Victor Mote



RE: FOP FAD design approaches

2004-07-12 Thread Victor Mote
Peter B. West wrote:

 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?

1. To process in units smaller than a page-sequence presents layout
dependency problems. An item on the last page of a page-sequence can
theoretically change the layout of something on the first page.
2. To process in units larger than page-sequence presents memory-usage
problems.

Except for things like unresolved page numbers in other page-sequences
(deemed to have an acceptable workaround), you can layout a page-sequence in
isolation from the other page-sequences.

BTW, although the main purpose of the FO Tree event-firing mechanism
(recently removed from HEAD) was to allow different layout engines to react
to page-sequence objects in different ways, one of the IMO advantageous
side-effects was that other high-level events could be fired as well,
allowing a layout engine to use something other than page-sequence as a
trigger. I thought at the time that this might be helpful to those wanting a
more eager layout strategy.

Victor Mote



out of office

2004-07-02 Thread Victor Mote
FOP Devs:

FWIW, I will be out of the office  away from email until about July 12.

I am pretty close to releasing a beta for FOray 0.1, but I still have a
sizable list of little things that need to be cleaned up. The big stuff is
pretty well straightened out. You are certainly welcome to look at it and
comment on it any time you wish, but I'll try to have something more
official and definitive after I get back. 

Victor Mote



RE: FOP site update

2004-06-29 Thread Victor Mote
Clay Leeds wrote: 

 Way ahead of you[1]! (I'm using the version re-created by 
 Victor--and 'improved' by me a little. I/we never got a 
 vector-based version of that one, even though I like the 
 'mirrors' version you linked to better. We need a 
 vector-based version so we can have resolution-independence).

I can see two vector-based versions in ViewCVS. The SVG version is here:
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/documentation/resources/images
/logo2.svg
The Adobe Illustrator version is here:
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/documentation/resources/images
/logo2.ai

Here is the concurrent mailing list discussion:
http://marc.theaimsgroup.com/?l=fop-devm=107091332015607w=2

Victor Mote



RE: Offline

2004-06-17 Thread Victor Mote
Peter:

Best wishes to you both.

Victor Mote 

 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, June 17, 2004 7:07 AM
 To: fop-dev
 Subject: Offline
 
 Fopfellows,
 
 I will be offline for the next week.  I'm marrying Jenni 
 tomorrow, and honeymooning in the frozen south of the South 
 Island of New Zealand for a week.  I'll post some photos to 
 my web site when I get back.
 
 Peter
 --
 Peter B. West http://www.powerup.com.au/~pbwest/resume.html
 



RE: SVG Generator

2004-06-12 Thread Victor Mote
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.

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.

Victor Mote



RE: Fonts

2004-05-25 Thread Victor Mote
. For example, if a Renderer
knows how to handle all 2300 (+/-) of Adobe's fonts, it seems like a good
thing for it to only have to respond to querys about the 3 that are actually
used in a document, rather than build all 2300 and tell the system about
each of them.

Thanks for the good feedback.

Victor Mote



RE: Fonts

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

  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.

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.

  Again, the underlying font is the same whether you are 
 rendering to PDF,
  Postscript, or anything else. Only the embedding would 
 change. Please let me
  know if I have missed something.
  
 
 Given a logical layout, the final result is determined by the 
 renderer's 
 notion of glyphs, their metrics and their relationships.  Is 
 this not so?

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.

If you'll give me a few weeks, I hope to be able to show you what I seem
unable to sell with words.

Victor Mote



RE: Fonts

2004-05-24 Thread Victor Mote
Clay Leeds wrote:

 On the subject of running headless, my experience has been to 
 pass it off to POSTSCRIPT--which, again in my 
 experience--runs fine headless. 

Off the top of my head, I can't think of a reason that the PostScript
renderer would work and the PDF renderer not work. I run all of my stuff in
a headless environment to PDF, with no problems. If you can provide some
details here, I am very interested to identify any RenderContext
differences.

Victor Mote



RE: Fonts

2004-05-24 Thread Victor Mote
Arnd Beißner wrote:

 To all of that I entirely agree, but might want to add one 
 thing: a renderer should have a way to supply a font to the 
 formatter's font repository. 
 This
 is needed when, for example, a print renderer can query and 
 use builtin printer fonts. The way to query and get these 
 (even if it's only a metrics-only
 font) should be in the renderer, though. Sometimes, this is 
 an essential feature, for example for special OCR/OMR fonts 
 stored in printers for which you may not have a screen font.

One of the changes that will probably need to be made to FOP's font handling
is to parse AFM files instead of PFMs. I have assumed that for hardware
fonts, either the device manufacturer provides font metrics files or enough
information so that they can be built. Adobe, for example, provides metrics
for the base-35 PostScript device fonts here:
ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/

So my *plan* has been that these fonts get treated pretty much like any
other font. The only thing about the hardware font is that it can't be
embedded -- it is already embedded all of the places that it can be.

Are you suggesting that FOP / FOray needs to actually query the hardware
device and extract metrics information directly from it? Or is the plan I
have outlined above sufficient?

Victor Mote



RE: Fonts

2004-05-24 Thread Victor Mote
Arnd Beißner wrote:

  So my *plan* has been that these fonts get treated pretty much like 
  any other font. The only thing about the hardware font is that it 
  can't be embedded -- it is already embedded all of the 
 places that it can be.
 
 Depends. Every PDF compliant reader/printer has to support 
 Adobe's standard Helvetica, Times Roman, Courier, Symbol and 
 Zapf Dingbats fonts (metrics-compatible alternatives at 
 least). So it makes sense for a PDF renderer to supply these 
 fonts metrics to a formatter to say hey, I can render these.

However, since these same fonts could also be used by the PostScript
renderer, or the Print or AWT renderers (assuming that the pfb is available
as well), I don't see a need to duplicate their definitions, or metrics, or
anything for each one of these environments, which is what it sounds like
you might be suggesting. It should be sufficient for the Renderer (or
RenderContext) to tell what it is *capable* of doing, without having to
provide the actual detail. In the case of the Base-14 font metrics, we can
and should and do embed them within FOP itself.

If you don't mind the metrics themselves living somewhere else, and the PDF
Renderer simply saying I can render Base-14 fonts, then we are in
agreement.

  Are you suggesting that FOP / FOray needs to actually query the 
  hardware device and extract metrics information directly 
 from it? Or 
  is the plan
 I
  have outlined above sufficient?
 
 Well, it really depends how far you want to go. Device fonts 
 have certainly seen days of higher importance... But still, 
 from time to time you stumble upon people who need (or want) 
 to use fonts that they have no exact software equivalent for. 
 Whether this means accessing the device directly or 
 indirectly using a printer driver or by means of supplying 
 metric files is a side issue, I think. Let's just say a 
 renderer should be able to supply fonts (metric-only or 
 complete) to the formatter.

Why is this better than simply supplying the same font metrics at a global
level, and letting the Renderer or RenderContext tell what it is/is not
capable of processing? What would one get in return for giving up that
simplicity?

 To give you an extreme example: In the high-volume output 
 market, the format of choice is still AFP by IBM. This is 
 (but today's standards) a rather obscure format that has 
 ancient origins in the GKS system and is very similar to the 
 metafile format in OS/2. Concerning fonts, however, you 
 mostly use bitmap fonts in the AFP world. Imagine a renderer 
 that has to support an output format that only allows (and 
 supplies) bitmap fonts.
 
 Sure, it's debatable whether one want to support this kind of 
 thing - at least by design. But, in any case, I think it 
 highlights the extremes that can happen in the font handling world.

After you have a generic font definition scheme, like an AFM parser or FOP's
metrics files, I think you can support any font, bitmap or otherwise. If the
hardware vendors can't provide the metrics, then someone would have to sit
down and either query the device or infer the metrics from output, or some
other method to get it into the standard form expected. It might be
worthwhile to add something in the font configuration that would identify
the point size, so that at least a warning could be generated if someone
tried to use, say, an 11-pt file at 9 points.

Victor Mote



RE: Fonts

2004-05-23 Thread Victor Mote
 not
everything wanting Font support needs the ability to embed a font in PDF,
while almost certainly anything creating PDF will want to embed fonts.

Victor Mote



FOray integration to FOP

2004-05-21 Thread Victor Mote
FOP Devs:

I apologize for intruding again. After thrashing around for a bit, I
concluded that there were an overwhelming number of good reasons for me to
import the entire FOP maintenance branch into the FOray repository, then
delete and modify as necessary for FOray integration. One of the biggest
benefits is that it will greatly simplify any integration that FOP decides
to do with Foray. Specifically, I don't have to be in the business of trying
to coordinate such integration, and you don't have to listen to me trying to
do that. Just come get it if you want it. The good news is that I will
essentially be doing the maintenance branch integration for you -- there
shouldn't be much to do except decide whether you want it or not. I have
posted greater detail here:
http://foray.sourceforge.net/fop/index.html

This approach allows FOray and FOP to ignore each other most of the time.
However, I obviously hope that you will check in from time to time to see
whether we have anything useful for you. Please let me know if I can help in
any way.

I will probably unsubscribe fop-dev in the next few days, so if I don't
respond here, contact me off-line or through FOray.

Victor Mote



RE: FOray integration to FOP

2004-05-21 Thread Victor Mote
Clay Leeds wrote:

 As you're aware, the Apache Software License 2.0 makes it 
 more cumbersome to include/bundle software that is not ASL. 
 Would you comment on the FOray 'license' and how it will be 
 affected and/or interact with ASL?

FOray officially uses the Apache License 2.0. ATM, all files still have the
1.1 boilerplate.

Victor Mote



RE: FOray integration to FOP

2004-05-21 Thread Victor Mote
Clay Leeds wrote:

 It might be good to put this on the FOray web site (I looked 
 for licensing info and didn't find any :-)).

Good idea. I just added it to the home page. You can also find it by
following the menu item SourceForge Project Page, which will take you
here:
http://sourceforge.net/projects/foray/

Victor Mote



RE: ANN: FOray

2004-05-19 Thread Victor Mote
Arnd Beißner wrote:

 Peter B. West [EMAIL PROTECTED] wrote on 19.05.2004 00:12:41:
 
  I think you are talking about different modularisation 
 contexts here. 
  You might want to clarify this part of the discussion with Victor.
 
 I really thought it was about the pluggable layout that 
 Victor brought up a long time ago. If not, just forget what I 
 said. 8-)

You are correct that LayoutStrategy, aka pluggable layout was at the heart
of the topic. And Peter is correct that the scope of modularization in LS
was at a different level than you were talking about. But I don't understand
Peter's point at all. If separation of concerns between page layout and
block layout is beneficial, then how much more so that neither of them
should be embedded in the FOTree??!! (Which FOP developers decided to redo
just last week). The fact that you are successfully modularizing trees into
branches and leaves is no argument against FOP modularizing the forest into
trees.

Victor Mote



RE: ANN: FOray

2004-05-19 Thread Victor Mote
Chris Bowditch wrote:

 I dont recall modularizarion being opposed. It was more a 
 case of Joerg saying 
 it would be a challenge and no one else stepping up to 
 support your proposals. 

When I left the project, there were 5 active developers, 1 for, 2 against, 2
neutral or silent. Joerg and I never disagreed on the difficulty of the
project, and it was not an impediment to me that others were busy doing
other things. But when active opposition emerged, it was time to cut bait.
This is all water under the bridge, and I only mention it because you
challenged my assertion. If FOray has any success at all, you all will have
another opportunity to address the issue.

Victor Mote



RE: ANN: FOray

2004-05-18 Thread Victor Mote
Simon Pepping wrote:

 2. modularize FOP's design
 
  I do understand why you have decided to start FOray. Although 
  modularisation is a nice feature, I dont see it as a key 
 goal for FOP.
  FOP's primary objective is to achieve a working layout. The main 
  things needed to achieve this are listed here:
  
  http://xml.apache.org/fop/design/layout.html#status
 
 I sympathize with this goal as well. I realize that that is 
 not quite in line with my reaction to Glen's recent patch. I 
 agree with Chris and Glen that it is not currently a key goal 
 for FOP. And since we do not have a strong proponent and 
 architect of a modular design, there is little point in 
 leaving bits and pieces in the code. But in the longer run, I 
 consider putting the FOP code in a modular structure as a 
 desirable thing.

If you guys are as close to having LayoutManager working as has been stated
in this thread (and I hope you are), then I agree that modularization would
not be the top priority. It is not an end in itself, but a means to an end.
When FOP was internally forked 2 1/2 years ago, the only thing that needed
to be rewritten from scratch was layout, but the whole project was forked
instead. Modularization would have prevented that, and allowed releases to
continue even though a chasm was being created and filled simultaneously.
The whole nature of refactoring anything is that you do it before you do the
real work. That is where FOray starts.

The real question on modularity was never whether it should be a priority,
but whether it hurt the project. On open-source projects, priorities are
really set by each individual. You fix the thing that hurts the most at the
moment, and that might be different for each developer. If I am working on
A, and you are working on B, as long as your work on B isn't bad for the
project as a whole, I have no right to complain. Nobody has yet put forth a
good argument against modularization, but it was opposed anyway. So now
we'll have a chance to test it in the real world.

Consider this -- what if the XSL spec hadn't been split into two pieces?
Would the part that we call Xalan today have its development stalled because
layout is stalled? If XSL-T and XSL-FO were all in one spec, would we be
smart enough to break the implementation into the two projects that it is in
today? All we are really talking about here is the principle of
encapsulation writ large.

Victor Mote



ANN: FOray

2004-05-17 Thread Victor Mote
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.

Victor Mote



RE: ANN: FOray

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

 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.

How, if FOray will closely parallel the HEAD development could it possibly
ha[ve] a great potential to de-stabilise FOP. If A = B, there could be no
reason to switch from A to B. There seems to be implicit in your comment a
nascent fear that maybe FOP really would benefit from being modularized.

The initial, relatively small, fork will be from the maintenance branch.
While it is being modularized, I will keep it in sync with my local copy of
the FOP maintenance branch code, and hopefully submit a patch to that branch
for your consideration. It is my hope that the benefits of this approach
will be compelling enough that someone will want to roll it into HEAD as
well, but that is your call, not mine. Depending on the success of this
approach and its reception, I'll decide whether forking other pieces is
needed (there are more extensive comments about this on the FOray home
page.) Some of those forks may well be started with code from HEAD.

WRT FOray's effect on FOP's stability, I don't see a need for any concern:
1. FOray's work is available to FOP (Apache 2 License), and I hope that FOP
(among others) will use it.
2. Most importantly, if I thought that there were FOP developers who shared
my zeal for modularizing FOP, I would a) not have left the project, and b)
would even now be trying to reenter FOP to do the work there. The very brief
review I took of the archives last week led me to believe that instead, the
baby steps I had taken toward my goals are being dismantled. (I'm not
offended, but merely reminded that I'm out of sync with you all.) Now, it is
possible that there are some developers not currently involved with FOP that
will be attracted to FOray. If there are compelling advantages to FOray's
approach, then that is as it should be. Further, if there are people who
see, for example, a benefit in having a freely-distributable alternative to
JAI, who want it for a totally non-FOP related purpose, and who contribute
to FOray, this seems like a net benefit to FOP. A similar situation would
exist for someone who wants to build an FOTree for a voice-related
application, use a well-crafted library of PDF-building routines, or write a
layout engine that was optimized for some particular axis.

There is no explicit intention to reconcile HEAD and maint. However, there
are several sets of circumstances that could have that outcome as a
byproduct. The biggest unknowns are the timing of LayoutManager's
completion, and the speed of progress in FOray.

WRT to the opportunity for funding, that had no part in my decision to use
sourceforge. (I did opt-in to accept contributions -- why not?). And I doubt
that serious funding will materialize through this channel. I would vastly
have preferred to do this within FOP for many reasons. My second best choice
was to find some other home on Apache for the independent modules, but I
frankly don't have time to jump through all of their hoops. The great
benefit to using sourceforge was the easy access. I can still get and
receive the benefits of an open-source approach and let you guys stay on
track with your work.

Victor Mote



RE: (Changing Vote) Re: [VOTE] Andreas L. Delmelle for committer

2003-12-31 Thread Victor Mote
Andreas L. Delmelle wrote:

  -Original Message-
  From: Glen Mazza [mailto:[EMAIL PROTECTED]
 
 snip /
  In particular, his recent handling of a messy
  disagreement between the committers a couple of weeks
  back was very helpful

 Good to see that it's considered to be helpful. I, myself, was
 not too sure
 at first about whether or not to put it in such strong wordings. Still not
 fully satisfied, though, but if Victor's still monitoring the
 list (closely
 or from a distance), I guess my intention is at least partly fulfilled.

I think you have misunderstood Glen's intent.

Cold turkey would have been better for me, but seemed irresponsible. I have
been monitoring the list to see if Jeremias would respond on the Driver
question. Any future correspondence needing my attention should be directed
to me off-list.

Victor Mote



RE: Setup code in Driver

2003-12-22 Thread Victor Mote
 asked why my code was being kept on my ISP.  He
 said that anyone had a right to fork the code, or words to that effect,
 IIRC.  It's a lonely path until you do manage to persuade others, but if
 you believe in it, back your judgement.

Well, I don't mean to give the impression that I don't believe in what I am
doing, but merely that I have been unsuccessful in my efforts to persuade
others. There is a PhD on fop-user who has more than once suggested that FOP
needs to be rewritten in Ada. Maybe he is right, but I don't think anyone
seriously thinks that we should make him a committer so that he can start
into that project, either on the trunk or a branch. The Java language, at
least for now, is a settled issue. The issue of monolithic vs. modularized,
while orthogonal to the language issue, is of no less magnitude. I thought
that the idea of accommodating patient processing through modularization was
a settled issue as well. I see now that it ain't and probably never will be.

So, I believe in what I am doing, but don't see a cost-effective way, and
probably no way at all, to get it done within the FOP project. I don't see
any need to drag those along who don't want to come. As I said in a previous
posting, if we're going to go in different directions, the next best thing
is to part in peace and work separately instead of against each other.
Whether that means forking the code, starting from scratch, throwing in with
some other project, etc. I don't know. That decision is immaterial to you.
But since you seemed to issue a challenge on the matter, I wanted you to
know that I do indeed believe in what I am doing.

Victor Mote



RE: Setup code in Driver

2003-12-21 Thread Victor Mote
Glen Mazza wrote:

 --- Victor Mote [EMAIL PROTECTED] wrote:
  Also, if possible, please let me know what you
  decide. I am evaluating
  in-progress projects right now to determine which
  ones I should finish and
  which ones I should abandon as I exit the project.

 You've mentioned before, I believe, there was some
 things you wished to do to improve the fonts.  That
 may be good--because most of us have not researched
 them.

The font work has to get thrown away. It is useless without configuration,
and there is no way I'm going to try to figure out what the team wants on
that issue. And actually it is pretty useless without a working layout
system. Jeremias knows at least as much about fonts as I do, and can
probably make faster progress with me inactive.

  If LayoutStrategy
  survives reasonably intact, I am much inclined to
  try to complete the port
  of the pioneer LS.

 I'd rather you not.  I don't want to have to maintain
 the 0.20.x layout strategy in addition to the 1.0
 strategy in 1.0.  The committers and contributors
 (Simon and Chris, in particular) are happy working on
 the improving 1.0 layout and wish to remain with it.

 Recent patches (hyphenation, borders) to 1.0 LS have
 made 0.20.x even more behind.  Also, the 1.0 Area Tree
 and Renderers are incompatible with 0.20.x LS, I don't
 want their architectures changed in order to
 accomodate it.

 Those who wish to use the 0.20.x layout strategy can
 continue to run 0.20.x.

 Let the decision to bring in that LS be with the ones
 who will have to maintain it.  As for me, getting one
 LS right is more than enough work.

For the sake of brevity and peace, I will ignore the factual and analytical
errors here, and simply say Thanks! That certainly makes my life easier.
It makes me realize again that maybe I was the one pulling against the flow.
My apologies to all, especially Peter.

Perhaps, in light of this, it may be worthwhile to abandon LayoutStrategy
entirely. That would solve Jeremias's problem that started this thread.

That actually leaves only one piece of unfinished business on my part -- the
static field lastFOTextProcessed in fo.FOText. This is used for
text-transform. It has been my intention to make that an instance variable
in PageSequence. However, there are some design-related issues that need to
be resolved before that should be done, and I intend to stay out of that. So
I mention it only to make sure that you know that I know that it shouldn't
be as it is, but that I don't see a ready solution. If multi-threading is
more important than text-transform, and you can't get the field converted to
an instance variable, just comment out the text-transform code.

Best wishes to all.

Victor Mote



RE: Setup code in Driver

2003-12-20 Thread Victor Mote
Jeremias Maerki wrote (Sent: Saturday, November 08, 2003 8:28 AM)

 As you may have seen in the CVS messages I have moved most of the setup
 code that was in the render() method to the getContentHandler() method.
 This is necessary because not everyone uses the render() methods,
 sometimes you simply need to have a ContentHandler to send SAX events to.
 Some of our examples (and some of our basic test cases) use that
 approach.

 What is left to do is to enable the FOTreeListener for Document that is
 currently added only if the render() method is called. Providing the
 same functionality with getContentHandler() only means you're not in the
 Driver class anymore when endDocument() is called on the ContentHandler
 which makes it difficult to remove the FOTreeListener on the
 FOTreeHandler when processing is complete.

 If noone objects, if noone has a better idea and if noone fixes that
 ahead of me, I'm going to write a ProxyingDefaultHandler as a utility
 class that does nothing other than pass through all method calls to
 another DefaultHandler (in other words: the FOTreeBuilder). I'll then
 add an anonymous inner class derived from that ProxyingDefaultHandler in
 getContentHandler that listens to the endDocument() event and calls
 removeFOTreeListener on FOTreeHandler. Instead of the FOTreeBuilder that
 anonymous inner class will be returned by getContentHandler().

First, my apologies for being so slow to respond. I am trying to clean up
some of this old stuff that I had flagged for followup. I also looked in the
CVS history  source, and it looks like you have not finished this yet.

The answer to your question probably lies in understanding how and why
getContentHandler() is used without also using render(). The FOTreeListener
is only needed if the input document is parsed, and in fact is only needed
if you want to break out of parsing to go do something at a higher level
before returning (the normal SAX events are not affected at all). So:
1) if the process running getContentHandler() doesn't ever parse, don't
bother registering the FOTreeListener
2) if the process running getContentHandler() doesn't care about being
notified about the end of a PageSequence (which is the only FOTreeListener
event that is *unique*), don't bother registering the FOTreeListener
3) otherwise, have it wrap its parsing code inside of the following (which
is what is wrapped around parser.parse in render() now):
before
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
foTreeHandler.addFOTreeListener(currentDocument);
}
/before

after
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
foTreeHandler.removeFOTreeListener(currentDocument);
}
/after

Better yet, refactor both of the above code snippets into methods that can
be called more simply, since this code would now be used more than once.

Just looking at what is left in render(), I don't quite follow why it would
ever *not* be used if parsing will take place. The only thing left in there
is parser.parse(), the above code that it is wrapped in, and the code to
*not* parse based on the LayoutStrategy's wishes. Since the parser itself
can be passed as a parameter, it seems like anybody parsing could/would use
it. If you will describe the use case(s) a bit, I'll try to be of more help.

Part of what is making this a bit ugly is that render() really belongs in
the Document class, but I don't think that can be done until FOP's API
issues are resolved.

Victor Mote



RE: Setup code in Driver

2003-12-20 Thread Victor Mote
 available to the method mentioned above that
handles the end of a PageSequence. FONode.getFOTreeControl() can be used for
the latter option. (FOTreeControl is the interface from FOTree to Document).
  b. FOTree independence needs to be abandoned. It was never totally
achieved anyway, and AFAICT I am the only one that thought it was very
important. Alternatively, an additional FOTree interface could be created to
which LayoutStrategy should conform.

  Part of what is making this a bit ugly is that render() really
 belongs in
  the Document class, but I don't think that can be done until FOP's API
  issues are resolved.

 Another top-priority todo item on my list that I haven't had time for,
 yet. *sigh*

Sorry, that was not meant as a dig at you.

I have deliberately avoided recommending anything above, as 1) I don't have
an interest in the outcome, and 2) I don't want to start any more fights.
However, please let me know if I can help resolve this. And I'm sorry to be
so dense on Cocoon -- I am familiar with its model at a user level, but must
have a false model in my head about how it does its work.

Also, if possible, please let me know what you decide. I am evaluating
in-progress projects right now to determine which ones I should finish and
which ones I should abandon as I exit the project. If LayoutStrategy
survives reasonably intact, I am much inclined to try to complete the port
of the pioneer LS. If not, then it would be unusable.

Victor Mote



RE: FOs and Areas

2003-12-18 Thread Victor Mote
 in between two words in
 one of Glen's posts ;) ) Things get rough sometimes, not everyone is as
 fluent in expressing himself in writing, and, as it turns out,
 not everyone
 seems to be as fluent in reading what is written...

Again you have misunderstood the issue. It is not that we do not understand
each other, but in fact that we understand each other too well.

Victor Mote



RE: Going away (was: FOs and Areas)

2003-12-18 Thread Victor Mote
Jeremias Maerki wrote:

 On 17.12.2003 15:25:37 Victor Mote wrote:
  I would rather go away than to be the guy that everyone wishes would
  go away.

 Ok, Victor, until that happens I'd like you to stay. I don't see *any*
 indication that *anyone* wishes that *anybody* should go away. Well, our
 moderators would surely like to get rid of all spammers. But seriously,
 please reconsider your decision, maybe take a break from the mailing
 list to clear your head. Consensus is sometimes hard to find especially
 over such an problematic medium such as this mailing list. Intentions
 are always difficult to transmit. Mails take a long time to write, time
 we usually don't have and would rather spend programming. I think we all
 share that frustration. Maybe we should all buy a webcam so we can
 occasionally chat together face to face as we're all a long way from
 each other.

It is true enough that consensus is sometimes hard to find, but that is
not the point. The point is that, as practiced by FOP, it is impossible to
find. And not because of technical difficulty.

WRT the slowness of the medium of email, I actually perceive that to be a
benefit. The time it takes to draft an email is a useful cooling-off period,
at least for me.

 Now the following is not only directed to you, Victor, but to everyone
 else as well. Just personal opinions:

 I followed the wars on the Avalon mailing list which at one time even
 produced a victim in form of a partial expulsion from the ASF. I would
 be very sad to have to see similar things here, especially in the
 project's present state.

 I told Glen this summer that it's better to fire away with changes than
 letting himself block by myself who, at that time, only injected his
 ideas and opinions but without code to back them. What this project
 needs is people who simply do it (tm). A good design is useful but
 obviously it's not so simple to find in our case. We can't live without
 some sort of design that gives use some direction but things like
 Victor's pluggable LayoutStrategy may really help, if we need to
 investigate different approaches. I'd rather have two or three
 half-completed layout approaches with lots of things learned than not a
 single working one with a community at total stand-still. We failed to
 integrate Peter's branch into HEAD but maybe that's also because it was
 too big a bundle at one time.

 Everyone should accept that another person has a different opinion. That
 shouldn't block us in our work. We all look forward to the same goal.
 That much I know or else we wouldn't be here.

 So, I mostly agree with Joerg's and Andreas' recent comments. Please
 let's focus on coding even if we may have to throw away little parts
 again in the process. (This doesn't mean I don't want to see anymore
 threads on design.) I think one of the most important points we learned
 since the redesign decision is to better split up the whole thing so
 it's easier (and less painful) to change if we run into a dead-end
 somewhere.

The inherent problem with this suggestion is that it is not reasonable to
invest in a project where the big design issues are not addressed. The best
thing would be to come to an agreement in theory, then as coding progresses,
change the theory if necessary. The second best thing would be to fork the
project into two -- one based on the trunk, one based on alt-design. If that
split were made official, I think developers would be much easier to recruit
(and retain) for both.

If Peter's principles prevail, it will be a permanent triumph of performance
over quality, and FOP will never be useful for my purposes. I don't have a
problem with that, but it is not unreasonable to try to resolve it before
investing more in the project.

Victor Mote



RE: FOs and Areas

2003-12-17 Thread Victor Mote
J.Pietschmann wrote:

 Victor Mote wrote:
  I guess you are saying that a page-sequence will use too much
 memory (??).
  Again, this is a non-issue. Just use a different LayoutStrategy
 that is more
  eager.

 This can be an issue. In a real world file I benchmarked
 (rendered to 58 pages),
 the FO tree for the second page sequence run up to 70MB due to a
 table with
 lots of small cells, which generated more than 80k FOs alone. This also
 generates a huge amount of areas, even if they are discarded
 almost as fast
 as possible, it is easy to max out a 512MB VM configuration. And that's by
 no means an completely unreasonable example.

 I wondered why I got a OutOfMemory already during *parsing*...

You must have missed the previous parts of the thread. Your response has
nothing to do with the issue being discussed. Yes, we can no doubt make the
parsing more efficient, the storage of the FO Tree less costly. But that was
not the issue on the table.

Victor Mote



RE: FOs and Areas

2003-12-17 Thread Victor Mote
Peter B. West wrote:

 The statements are getting extreme.  Let's just agree to differ.  I'm
 happy to let my code and the design that underlies it do my talking.

OK. For the reasons already mentioned, this does not work for me. I consider
this kind of behavior to be uncivilized. However, I have to consider the
possibility that the problem lies with me. Since this is the second time in
the last several months that I have had to call someone out for unsupported
(and unsupportable) conclusions, and since I have had to do so alone, and
indeed stand alone here, it seems probable that this is just the way things
work, and that I should somehow adapt myself to it. That ain't going to
happen. I would rather go away than to be the guy that everyone wishes would
go away. So, adios.

I have a great amount of respect for everyone on this team, and wish you all
well. I very much regret leaving my various interests in the project
unfinished.

Victor Mote



RE: FOs and Areas

2003-12-16 Thread Victor Mote
 accountable for the agitation on the issue
at hand. And, as you well know, this is a big issue. The resolution of
smaller downstream issues rely on the resolution of the bigger upstream
issues. IMO you owe the project one of the following: 1) to throw in with
the trunk design, 2) to explain in logical, supportable terms why your
design is better, or 3) to expect the rest of us to ignore it.

 I realize the tone of this posting has not been entirely irenic.  I'll
 try harder.

And I apologize for my part in this desultory conversation. If anyone thinks
I am out of line here, I'll be happy to find something more productive to do
with my time.

Victor Mote



RE: (Victor et al) Re: Performance improvements.

2003-12-15 Thread Victor Mote
Peter B. West wrote:

 Victor Mote wrote:
  Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
  object creation, why create a MinOptMax object? Why not just return the
  three resolved values in separate methods. Anything that uses the
  information will have to separately address the 3 pieces of
 data anyway, so
  I don't see any advantage to packaging them in an object.
 

 In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM)
 etc.

 Speaking of the minimal API, why not PropertyValue getPropertyValue(int
 propertyIndex)?  This is presumably defined on FONode or some such, and
 FONode also presumably knows how to navigate the FO tree and related
 Area tree in order to resolve percentages and the like.

That may be OK for the internal-to-FO-Tree logic, but I don't think is
suitable for the API, primarily because you are locked into one signature
for all properties. 1) There may be some properties for which we want to
return a non-integer value (Font object, for example). 2) There may be some
properties for which we wish to pass more information. 3) You are going to
have some ugly case or switch logic that has to determine which property is
being dealt with. My opinion is that this is not a sound approach.

Victor Mote



RE: (Victor et al) Re: Performance improvements.

2003-12-15 Thread Victor Mote
Peter B. West wrote:

 Glen Mazza wrote:
  --- Peter B. West [EMAIL PROTECTED] wrote:
 
 See above.  In alt.design, all compounds are
 shorthands, and all
 shorthands are presumed to have been resolved into
 their components
 during FO Tree building.
 
 
 
  BTW, does Alt-Design already resolve the cases where
  *both* a shorthand and one of its included components
  are specified?  I.e., (usually, I believe), disregard
  the shorthand value for that component and use its
  explicitly given value instead?
 

 It's in the ordering of the properties.  There is a simply for loop to
 process properties (attributes, in fact) defined on an FO.  The order of
 definition ensures the correct order of evaluation - shorthand first,
 then any individual properties.  The same goes for corresponding
 properties, when I get around to doing them.  Check the order of
 properties in PropNames.java.

I don't know how to reconcile this with your previous posting:

 See above.  In alt.design, all compounds are shorthands, and all
 shorthands are presumed to have been resolved into their components
 during FO Tree building.

The previous posting seems to indicate that the properties have been
decomposed, the chronologically latter posting seems to indicate that the
shorthand retains its shorthand character. The critical thing here is that
the API not even allow anybody to ask about shorthand or compound
properties. The API should allow requests only for the decomposed
properties, and the FO Tree should resolve all of this before passing a
value back.

Victor Mote



RE: FOs and Areas

2003-12-15 Thread Victor Mote
 for
 reprocessing on the next page.  It is this pushed-back line-area which
 generates the initial demand for more space.)

This is currently handled through the area.AreaTreeModel concept, which is
pretty cool, except that I need to get the LayoutStrategy involved with
choosing which model to use. (Some LayoutStrategies by definition don't want
to spit out pages too quickly, which is what you have proposed).

 This demand percolates up through the flow active ancestry until it
 results in a demand for a new page.  The page factory associated with
 the page-sequence and the layout-master-set through the page-sequence
 master-reference, generates a new page container set, and the relevant
 area and its dimensions are passed to the flow FO.  From here the
 container availability percolates back down the active flow descendants,
 with the FO nodes generating new sub-areas, and attaching percentage
 expressions to their reference areas as control descends.  At the
 bottom, the line-area generators are given new dimensions to deal with,
 and the bottom-up filling process begins again.

 I want to diagram this, and look more closely at the nasty cases as I
 do, but comments are, as always welcome.  Victor will be upset, I know,
 but I can't see the separation of FO tree building and Area tree
 building.  Keiron may be screaming, That's what I was doing,  in which
 case my apologies.

OK, I am upset, but not for the reason that you think. Rather than answering
the thread that we already had active on this topic, you have chosen to
start a new one. This is now at least the third time you and I have been
down this path. I don't know the history behind why alt.design is on a
separate branch, but these issues were probably hashed out back then as well
(before my time).

Much of the work I have done over the past six months has been, consistent
with good design principles, to make it easier to accommodate your layout
ideas, including doing your own FO-Tree-like thing, without rewriting all of
the rest of the code. (Don't get me wrong -- your code is not the *only*
reason I have made these changes, but it has been a big part of the
thinking). The trunk code is now flexible enough for you to drop in your
code as a LayoutStrategy. What galls me is that you insist that everyone
else must adopt your approach as well. I guess I'll do that when I see that
it is, on balance, superior. You won't give me any theoretical ideas why
that should be, and AFAICT, there is no practical evidence that it is
superior either. (I am talking about FOTree/AreaTree here, not your
properties handling, which has been recognized for some time as having some
merit).

Until you are ready to prove the superiority of your design, my humble
suggestion is that you drop it in as a LayoutStrategy, and keep working on
it. This makes the most upstream common code that you use the AreaTree
itself.

I have stated before that our multiple lines of development are our biggest
problem. I was wrong. As bad as that is, the constant agitation of design
issues that should be resolved and documented is even worse. Design by
committee is a horrible idea anyway, but when people ignore critical threads
and continue beating the drums anyway, it is downright unbearable.

Victor Mote



RE: (Victor et al) Re: Performance improvements.

2003-12-15 Thread Victor Mote
Peter B. West wrote:

 If we go towards integer representation, properties in the API will
 always be represented by integers.  By looking at this particular
 signature, we are not locking ourselves in.  We can add other signatures
 if the need arises, but they can be extensions of the basic call.

 The above call does not return an int or an Integer, but a PropertyValue.

 public PropertyValue getPropertyValue(int property)

 is, in fact, the signature from FONode.java in alt.design.

OK. I'll interpret this as a firm -1 on my API proposal, which is sufficient
to deep-six it. I think it will be a net benefit for the project for me to
withdraw from the remainder of the Properties discussion.

Victor Mote



RE: (Victor et al) Re: Performance improvements.

2003-12-13 Thread Victor Mote
Glen Mazza wrote:

 Thanks, Finn and John Austin, for your efforts here.

Yes, and Peter, too.

 Victor, not to rush you, but how agreeable are you in
 general on switching to integer enumerations for FOP
 properties?  (Given Alt-Design, Peter obviously
 approves.)  I checked Alt-Design's PropNames.java[1]
 and liked what I saw.  It doesn't necessarily have to
 be that particular design, just the idea of integer
 constants in general.

That is fine. I hope nothing I have said would be interpreted to the
contrary, and I can't imagine why you might think that this proposition
rushes me (were you waiting on me for something?). I have the least
knowledge of or interest in the performance side. Having said that, I *very*
much want us to implement a lowest-common-denominator,
it-will-never-matter-what-the-guts-look-like API for the FO Tree to deliver
the property values. That is totally independent of the way properties are
stored and computed.

Victor Mote



RE: (Victor et al) Re: Performance improvements.

2003-12-13 Thread Victor Mote
Peter B. West wrote:

  It would be really nice to have a getLeaderLength()
  which returns a MinOptMax. this means the getLeaderLength()
  has:
   - resolve percentages and functions
   - deal with the leader-length shorthand setting before this
   - deal with inheritance (n/a here, fortunately)

 Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(),
 with all values resolved.

Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
object creation, why create a MinOptMax object? Why not just return the
three resolved values in separate methods. Anything that uses the
information will have to separately address the 3 pieces of data anyway, so
I don't see any advantage to packaging them in an object.

Joerg speaking here/
  One of the complications in the maintenance code is that
  the code in the FO layout routines had to deal with resolving
  percentages. OTOH, the generator is mainly so ugly because
  Keiron et al. tried hard to press the shorthand handling
  into a common scheme. There should be better solutions for
  either problem.

Nobody but the FO Tree should ever have to think about compound or shorthand
properties. AFAICT, all examples of these can be decomposed into their
components. The FO Tree's API should deliver only the decomposed (i.e.
lowest-common-denominator or LCD) values. And yes, definitely, percentages
should be handled on the FO Tree side. Make FO Tree do all of that work.

Victor Mote



RE: (Victor et al) Re: Performance improvements.

2003-12-13 Thread Victor Mote
J.Pietschmann wrote:

 If we are at it, I'd vote for dumping generating the property
 classes and check the java files into CVS.

+1. I have noted Finn's and Glen's subsequent objections, and Joerg's
subsequent comments. I agree that the general need for that level of
flexibility has passed, and that these things *should* be rewritten in a
more OO way. I may be wrong, but I think most of these classes will
disappear after this stuff is properly rationalized. The vast majority of
the values can be reduced to primitive data types that can be stored
directly in FO Object instances.

I think one other advantage of the generated code was that it was easier to
deal with whether a property was supported or not. However, support for
properties now needs to be handled by the LayoutStrategy implementations.
IOW, as far as FO Tree is concerned, it handles all objects and properties,
and should remain agnostic about how that information may or may not be
used.

Victor Mote



RE: [PROPOSAL] Remove ant.jar and build.bat/sh

2003-12-11 Thread Victor Mote
Peter B. West wrote:

 Removing ant, fair enough, but why the build scripts?  Shouldn't they be 
 extended a little to check for the presence of an ant installation and 
 make appropriate noises if one isn't found?

I agree.

Victor Mote


RE: FOP logo update

2003-12-08 Thread Victor Mote
OK, there it is, in the same directory as the svg file.

Victor Mote

 -Original Message-
 From: Clay Leeds [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 05, 2003 3:39 PM
 To: [EMAIL PROTECTED]
 Subject: Re: FOP logo update
 
 
 Victor Mote wrote:
 Clay Leeds wrote:
 
 I was unable to make much progress on this topic. I am unable to get
 SVG and/or vector versions of the logo. We do, however, have a JPG
 version.
 
 Thanks for your efforts here. I'll work on creating an svg version.
  
  I just checked in src/documentation/resources/images/logo2.svg, 
 which is the
  first pass at an svg version of the new logo. Please let me 
 know if you have
  any comments, even if you think that it is OK as is. I know 
 some wanted to
  tweak it, and this is probably not a perfect image of the 
 original design
  anyway. Also, does it make sense to check in the Adobe 
 Illustrator file that
  was used to create it? That might make editing it easier.
  
  Victor Mote
 
 I think it makes sense to check in the Illustrator file used to create 
 the file. I'll check it out and let you know what I think.
 
 Web Maestro Clay
 


  1   2   3   4   5   >