RE: character

[Arved Sandstrom]

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: October 6, 2002 12:00 PM
 To: [EMAIL PROTECTED]
 Subject: Re: character


 Arved Sandstrom wrote:
  Why is character=- a parsing error? The XML Recommendation
 has at least
  one example of an attribute value that contains a hyphen.

 This comes from assuming that every unqoted sequence of characters which
 is not a number, mesutrement or a color has to be interpreted as NCName,
 as the grammar suggests, and IIRC a NCName must not start with a hyphen.
 This means
   hyphenation-char=-
 can't parse as number, can't parse as string, can't parse as color, can't
 parse as NCName  - parsing error.

Hi Joerg

Can you cite the specific productions that lead to this conclusion? I am not
saying that you are wrong but I can't find it.

I must be tired. ;-) I just looked at the XML 1.1 production for AttValue
which is

AttValue::='' ([^] | Reference)* ''
   |  ' ([^'] | Reference)* '

and I see a prohibition here on using a literal '' or '' in the attribute
value, anywhere. But I see nothing about '-'.

If the grammar of the recommendations leads to the conclusion that

character=-

is not OK, then this just simply offends my common sense.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: character

[Arved Sandstrom]

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: October 6, 2002 12:39 PM
 To: [EMAIL PROTECTED]
 Subject: Re: character

 Arved Sandstrom wrote:
  Can you cite the specific productions that lead to this
 conclusion? I am not
  saying that you are wrong but I can't find it.
 
  I must be tired. ;-) I just looked at the XML 1.1 production
 for AttValue
  which is

 Don't look at XML AttValue, look at the XSLFO property expression
 language.
 Somehow it is implicit that all attributes in a XSLFO document are parsed
 as expressions which are defined in 5.9 Expressions. Refer specifically
 to 5.9.3 Basics. A single hyphen is not a valid expression according to
 the XSLFO expression grammar.
 Maybe some fallbacks are implicit somewhere, I don't know.

An Expr can be a Literal, the production for which is

'' [^]* ''
| ' [^']* '

If I look at the first alternative,

'' [^]* ''

it seems to me that I have pretty considerable leeway, and - isn't ruled
out at all.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: character

[Arved Sandstrom]

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: October 6, 2002 1:29 PM
 To: [EMAIL PROTECTED]
 Subject: Re: character
 
 
 Arved Sandstrom wrote:
  An Expr can be a Literal, the production for which is
  
  '' [^]* ''
  | ' [^']* '
  
  If I look at the first alternative,
  
  '' [^]* ''
  
  it seems to me that I have pretty considerable leeway, and - 
 isn't ruled
  out at all.
 
 Erm, the expression is supposed to be inside the XML attribute quotes,
 for example hyphenation-char='-' would be ok (literal, second
 production), but hyphenation-char=- does not match the literal
 production, nor any other (except operator). Unless I missed
 something, of course.

And unless _I_ am missing something, - precisely matches that production.

You are looking at

' [^']* '

but I am looking at

'' [^]* ''

According to the latter I can absolutely do -.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: character

[Arved Sandstrom]

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: October 6, 2002 2:15 PM
 To: [EMAIL PROTECTED]
 Subject: Re: character


 Arved Sandstrom wrote:
  And unless _I_ am missing something, - precisely matches that
 production.
 
  You are looking at
 
  ' [^']* '
 
  but I am looking at
 
  '' [^]* ''
 
  According to the latter I can absolutely do -.

 Well, in
hyphenation-char=-
 the hyphen is the expression, not the hyphen surrounded by double
 quotes. As I said, unless I'm something missing, the FO property
 expression is the value of the XML attribute, which in turn is the
 hyphen, because the double quotes are part of the XML syntax and
 are stripped by the XML parser. The XSLFO property expression parser
 gets the hyphen, without any quotes, double, or single. And without
 the quotes, it does not match either of the two productions for literal.
 This is the problem here.

 Perhaps I should have written that
hyphenation-char='-'
 and
hyphenation-char='-'
 as well as
  hyphenation-char='quot;-quot;'
 are legal, while neiter
  hyphenation-char='-'
 nor
  hyphenation-char=-
 are ok.

Yes, I see your point.

I think they screwed up the grammar. As I stated before, I find it ludicrous
that character=- would not be OK.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: A performance patch for PDFInfo class

[Arved Sandstrom]

 -Original Message-
 From: Kevin O'Neill [mailto:kevin;rocketred.com.au]
 Sent: November 11, 2002 5:47 PM
 To: FOP Developers
 Subject: Re: A performance patch for PDFInfo class

[ SNIP ]
 String buffers are used by the compiler to implement the binary string
 concatenation operator +. For example, the code:

  x = a + 4 + c


 is compiled to the equivalent of:

  x = new StringBuffer().append(a).append(4).append(c)
.toString()


 So the first recommendation is to use String + for this type of
 method, it's easier to read and runs faster.
[ SNIP ]

This kind of thing is discussed by Jack Shirazi at length, also.

The thing is, there has long been a blanket instruction, don't use String
concatenation. Programmers learn it by fiat, and never think it through. In
fact, it should be obvious to any programmer (if they are encouraged to
think, that is) that concatenation of literal Strings is not something to
avoid. Assuming a decent compiler.

Regards,
AHS


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [VOTE] Victor as committer

[Arved Sandstrom]

+1.

 -Original Message-
 From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
 Sent: November 20, 2002 5:23 AM
 To: FOP
 Subject: [VOTE] Victor as committer
 
 
 Hi Developers,
 
 I propose we have a vote for Victor to become a committer.
 
 Plenty of eagerness shown already and I am sure he will do lots more for
 the project.
 
 Here's my vote:
 +1
 
 
 Keiron.
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [VOTE] Victor as committer

[Arved Sandstrom]

Realistically I should be considered inactive myself. Thanks for bringing
this up, Art.

I just happen to have a brutal workload at the moment and I don't see it
lessening in the next 4 months, minimum. It's fun stuff - I love it - but at
the end of a workday I can't stand to look at code much, and same goes for
weekends.

I am not disinterested in Fop and will attempt to continue providing input.
I haven't stopped monitoring the lists. But until such a time as I can
contribute code I should be considered inactive.

Arved

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: November 20, 2002 3:43 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [VOTE] Victor as committer


 Ok, I guess that answers my question. Sorry I was too lazy to look that up
 on my own. So my understanding is that only committers may vote, as per:

 A Committer has write access to the source code repository and
 gains voting
 rights allowing them to affect the future of the subproject.

 Putting this with the following:

 At times, Committers may go inactive for a variety of reasons. A
 Committer
 that has been inactive for 6 months or more may lose their status as a
 Committer. Getting access back is as simple as re-requesting it on the
 project's Developer mailing list

 I assume that being inactive means that I have lost my status as
 a committer
 and hence may not vote.

 So, hopefully one of these days (I have no idea when) I will again be able
 to contribute to FOP and re-attain committer status. At the
 moment, I am not
 actively working with FOP at work, but we are still using it (actually a
 version from a long while back - around the last time I contributed
 anything). The good thing is that I have not been called in to resolve any
 problems with FOP, the bad thing is that this is probably largely
 because of
 the limited use case. I hope in the future to expand this, which
 will likely
 entail some contributions to FOP. Or maybe by then my efforts will not be
 necessary - this would also be cool, although a bit disappointing
 in that I
 was not a part of it...

 Art (inactive)

 -Original Message-
 From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 20, 2002 2:18 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [VOTE] Victor as committer



 Venkata Rao Nadella wrote:
  Hi,
 
  I joined this list recently. I don't know anything about committer.
  Can someone let me know about committer?

 http://incubator.apache.org/drafts/glossary.html
 http://jakarta.apache.org/site/roles.html

 --
 Nicola Ken Barozzi   [EMAIL PROTECTED]
  - verba volant, scripta manent -
 (discussions get forgotten, just code remains)
 -


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Alt-Design status: XML handling

[Arved Sandstrom]

 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]]
 Sent: November 26, 2002 3:25 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Alt-Design status: XML handling

 Rhett,

 To comment on only two aspects of your posting.

 Rhett Aultman wrote:
 
  -Original Message-
  From: Oleg Tkachenko [mailto:[EMAIL PROTECTED]]
 
  Generally, event-driven processing is a pretty good thing.  The
 critical issue with it, though, is the ratio of event production
 to event processing.  If that number is anything greater than 1,
 then more events are being produced in a stretch of time than can
 be effectively processed in that stretch of time.  Events start
 to queue up, taking up memory.  If it happens enough, the heap
 starts to get a little too full, the gc runs a little too much,
 and that causes processing time to suffer even further.  Under
 most circumstances, event-based processing is like using a garden
 hose to water a bed of flowers.  It works just fine.  Under more
 intense cases, though, it can be more like using a garden hose to
 fill a small container of water, then leaving the hose laying
 around (spilling water all over the lawn) while the container
 gets carried off somewhere.

Actually, it really matters where the events are coming from. An HTTP server
has no control over how many requests it gets, so your description above is
apt. But for FOP (disregarding FOPServlet) everything is one process - the
XML parser, the formatter, the renderer - so it's ultimately procedural;
there may be an internal boundary where an event/callback system is used,
but it's all one thread so nothing queues up at all.

The only reason to adopt your approach (and I am not saying I don't like it)
is because it's easier to understand.

Regards,
Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Still on for freeze deadline?

[Arved Sandstrom]

Considering that our new chief executive is Greg Stein, I'd be surprised if
this isn't on the horizon. :-)

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: December 1, 2002 4:12 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Still on for freeze deadline?


 Jeremias Maerki wrote:
  Moving around directories on the server so we don't lose history on
  files. See my proposal on directory structure reorganization, ex.
  moveing src/org to src/java/org.

 Any chance to get the ASF interested in SubVersion?
   http://subversion.tigris.org/

 Apart from being accessible through firewalls, it allows moving
 files and directories, while being largely CVS compatible for
 everything else.

 J.Pietschmann


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Redesign issues

[Arved Sandstrom]

Response below.

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: December 7, 2002 7:16 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Redesign issues

[ SNIP ]
 Now the biggest issue: the layout managers itself. At the first
 glance it is
 not obvious why they should be first class objects at all, in
 particular as
 a cursory examination of the code shows a one-to-one correspondence to FOs
 both for classes and instances. Well, layout managers abstract the layout
 *process*, however, the deep layout manager class hierarchy is
 mainly designed
 around code reuse, which makes it really hard to understand.
 There is a reason
 that design rules recommend against overuse of inheritance for
 code reuse and
 deep inheritance hierarchies. There is only so much someone can
 hold in the
 brain. Nevertheless, this is something I don't know how to fix on
 the cheap.

I actually helped push for this last year - the notion of separate layout
managers. I was strongly influenced by the mess that FOP code had become at
the time, and really thought that layout should be taken out of the FOs
themselves; that the FO's, in a sense, were (or should be) just value
objects.

I worked on an xslfo-proc prototype (in Perl) for months earlier this year.
I started out with the layout manager idea. It became increasingly clear to
me that there was in fact a natural 1-1 correspondence between managers and
FOs. I had a prototype, incidentally, which properly handled
reference-orientation in all regions, and even took RO down to
block-containers, something which no implementation (not FOP, not XEP, not
XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly,
which I don't know.

It's also interesting, Joerg, that you should mention a hard to understand
layout manager class hierarchy...this is also what inevitably developed in
my prototype. So at some point (and I think there are comments and emails to
support this) I eventually came back to the thought that there is nothing
wrong with individual FOs being able to do their own layout. Which is
actually the existing maintenance stream FOP model.

I'll have some more to say laterthese are immediate comments. I am just
struck by the fact that it is now December 2002 and we are not where we want
to be, not even close, which is providing an open-source Extended
conformance XSL processor to the hungry, huddled and poor.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Redesign issues

[Arved Sandstrom]

 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]]
 Sent: December 9, 2002 8:56 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Redesign issues


 Keiron Liddle wrote:
 
 
  I still believe that it is useful to have the layout managers separate
  from the fo tree. There are a number of reasons that come to mind. It is
  possible to independantly change layout managers. Certain fo's aren't
  directly in the same hierarchy: markers, undefined table columns, table
  cells under table body. Then there are things like floats and footnotes
  that can gain from this.

 Keiron,

 I'm inclining in this direction myself, because I am interested in
 isolating the layout/area tree functions as much as possible from the
 raw information stream of the FO tree.  I tend to view the FO tree as a
 read-only data source for the layout. manaaged by the Fo objects.

The feeling I got from my prototype is that there is not much commonality.

Markers - there is no logic here that has anything to do with layout, per
se. The content goes into a static-content and hence does not influence page
break decisions. The logic for handling markers can be confined to the
document level. root is an FO - it is the document, so it is the FO that
can handle this.

Floats and footnotes - the float goes on a page or it doesn't. The footnote
starts on page N and continues through N+x or it doesn't. What FO knows
about pages? The page-sequence...that's the natural FO for handling float
and footnote problems. OK, this is somewhat simplified; with floats it may
come down to columns, and then it is the region-body that also needs to
intercede.

Tables I can't comment on. So there may be an argument here for independent
layout managers.

I think we could use layout managers when it is clear that there is a layout
problem involving N FOs, such that those N FOs are not identical to the
children of a higher FO. I see keeps as being the main occurrence of this.
But even then, keeps are still related to logic that occurs in page-sequence
and region-body and lines (3 entities, in other words), and the nature of
that logic differs in all 3 situations, so is it worth abstracting out a
keep manager? I don't know.

Here's a common ground that I can agree on...pull the layout logic out, and
put it in managers. This is not going to hurt. But really, really cut down
on the urge to re-use managers through an inheritance hierarchy. I think
this is also Joerg's point. It obfuscates more than it helps.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Redesign issues

[Arved Sandstrom]

Responses below.

 -Original Message-
 From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
 Sent: December 10, 2002 5:56 AM
 To: FOP
 Subject: RE: Redesign issues


 Hi Arved,

 On Mon, 2002-12-09 at 20:30, Arved Sandstrom wrote:
  The feeling I got from my prototype is that there is not much
 commonality.
 
  Markers - there is no logic here that has anything to do with
 layout, per
  se. The content goes into a static-content and hence does not
 influence page
  break decisions. The logic for handling markers can be confined to the
  document level. root is an FO - it is the document, so it is
 the FO that
  can handle this.

 That is true but there is something that happened in the original way
 that fop handled markers.
 The fo has a property list which has a parent property list from the
 parent object. It also has a parent object. It couldn't be simply made
 null and then passed to the root as it could cause npe's.

 The argument here is not so much that it cannot be done, more that if it
 is a completely separate logic then it is easier to understand and
 ensure it won't end up with bugs or memory leaks.

Right...I implemented the original (incomplete) marker logic using what we
had at the time for property handling. I did not tackle the re-parenting
problem at all - didn't get that far - so the marker content actually
retained the inherited properties from the origin FO, which is incorrect.

I see no problems with a marker handler that associates with the document,
in this case. This would coordinate with page-sequences and pages,
obviously.

Incidentally, I still think that the way markers are described in the spec
is vague and confusing. Perhaps we should hammer this out.

  Floats and footnotes - the float goes on a page or it doesn't.
 The footnote
  starts on page N and continues through N+x or it doesn't. What FO knows
  about pages? The page-sequence...that's the natural FO for
 handling float
  and footnote problems. OK, this is somewhat simplified; with
 floats it may
  come down to columns, and then it is the region-body that
 also needs to
  intercede.
 
  Tables I can't comment on. So there may be an argument here for
 independent
  layout managers.
 
  I think we could use layout managers when it is clear that
 there is a layout
  problem involving N FOs, such that those N FOs are not identical to the
  children of a higher FO. I see keeps as being the main
 occurrence of this.
  But even then, keeps are still related to logic that occurs in
 page-sequence
  and region-body and lines (3 entities, in other words), and the
 nature of
  that logic differs in all 3 situations, so is it worth abstracting out a
  keep manager? I don't know.

 There is the line layout manager. There is no line fo. The block layout
 manager is able to collect inline porducing layout managers and give
 them to a line layout manager which then has the logic to handle flowing
 inline areas into a line.
 The block layout logic is then more simple.

Lines are not FO's, no - that's why I used the word entity. :-)

 This is similar to the cells under a table body.
 Also with page columns, do we want to make the FlowLayout manager handle
 all the blocks that do and don't span columns or can we create a page
 column layout manager which looks after blocks in columns and then can
 handle the reflowing etc.

I originally handled this (in my prototype) with managers for pages,
regions, spans and columns. This is the one area where I think managers make
the most sense - the handling of a page is complex and it simplifies matters
to have clearly distinguishable managers to take care of the various
constituent areas.

 A leader with use-content creates an inline parent with a fixed width.
 It is creating a simple inline area but we want to do a quick
 independant layout for the content.
 Again, maybe not necessary but it help separate out the logic.

  Here's a common ground that I can agree on...pull the layout
 logic out, and
  put it in managers. This is not going to hurt. But really,
 really cut down
  on the urge to re-use managers through an inheritance hierarchy. I think
  this is also Joerg's point. It obfuscates more than it helps.

 I'm not sure the exact re-use problem you are referring to but I agree
 it should be simple and straight forward.

Agreed. I won't comment further until I re-sync with the latest CVS and
examine. :-)

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

Not to sound bitter, but it would have been nice to know about this sooner.
This pretty much usurps what I and Eric Bischoff have been doing (when we
can); I sort of figure it didn't get written in the last month either. Any
reason for the blasted secretiveness?

Arved

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: December 13, 2002 12:09 PM
 To: [EMAIL PROTECTED]
 Subject: Sun XSL Formatter


 Peter did ask...

 

 The Sun xmlroff XSL formatter is written in C, and it uses
 libxml2 and libxslt plus the GLib, GObject, and Pango libraries
 that underlie GTK+ and GNOME (although it does not require either
 GTK+ or GNOME).

 The formatter currently produces PDF output only.

 xmlroff is a command line program, but the bulk of the XSL
 formatting is implemented as a libfo library that can be linked
 to any program that requires XSL formatting capability.

 It will be available under a BSD license.

 It is being developed on both Solaris and Linux.

 The formatter is awaiting final approval before the code can be
 made public source.  An announcement will be made on xsl-list,
 www-xsl-fo, and XSL-FO@YahooGroups once the code is available.

 Regards,


 Tony Graham
 XML Technology Center
 Sun Microsystems Ireland

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

Well, Java or C or C++ or Haskell, it would have been nice to have a clue.

We have an ASF tradition of developing communities...this kind of stuff that
Sun and IBM does is getting old. Don't open-source it; sell it. I will argue
against its adoption into Apache.

Arved

 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]]
 Sent: December 13, 2002 8:43 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Sun XSL Formatter


 Arved Sandstrom wrote:
  Not to sound bitter, but it would have been nice to know about
 this sooner.
  This pretty much usurps what I and Eric Bischoff have been
 doing (when we
  can); I sort of figure it didn't get written in the last month
 either. Any
  reason for the blasted secretiveness?
 

 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]

 Subject: Sun XSL Formatter
 
 
 Peter did ask...
 

 Tony,

 Thanks for the response.  I must say, though, that had the product been
 written in Java, I would have been asking the same question as Arved.

 Peter
 --
 Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
 Lord, to whom shall we go?


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

 -Original Message-
 From: Peter S. Housel [mailto:[EMAIL PROTECTED]]
 Sent: December 14, 2002 2:21 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Sun XSL Formatter


 Arved Sandstrom [EMAIL PROTECTED] writes:

  Well, Java or C or C++ or Haskell, it would have been nice to
 have a clue.
 
  We have an ASF tradition of developing communities...this kind of stuff
 that
  Sun and IBM does is getting old. Don't open-source it; sell it. I will
 argue
  against its adoption into Apache.

 Googling for xmlroff yields:

 http://www.plurb.com/webservices/UBL4.pdf

 Looks like they want to donate it to Gnome, not Apache.

 Despite your not wanting to sound bitter, your protest still sounds bitter
 anyway.

 -Peter-

No bitterness at all, actually, Peter. It takes a bit of wind out of my
sails, sure, since xmlroff is so similar to the project that Eric Bischoff
and myself were working on. Tony has certainly been aware of that for quite
a long time - I don't understand why the secrecy, myself, seeing as how we
are now looking at an OSS donation anyway.

I'd be bitter if I were so arrogant as to think of myself as being upstaged.
:-) That's not the case. I am quite familiar with the spec, and there are
now a number of competing efforts. None of which are quite accurate. So
there is room for more competition. Alternatively, I may talk to Tony and
Eric and see if we can assist.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

 -Original Message-
 From: Victor Mote [mailto:[EMAIL PROTECTED]]
 Sent: December 14, 2002 3:01 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Sun XSL Formatter


 Peter S. Housel wrote:

  Looks like they want to donate it to Gnome, not Apache.

 AFAIR, the BSD license is pretty incompatible with the Apache license. One
 of the reasons that the xmlroff announcement doesn't change my
 commitment to
 FOP is that, for my interests anyway, the Apache license is
 superior. Others
 are that it is not written in Java, and only runs on
 Sun-supported operating
 systems. It almost seems like Java was bypassed because it runs
 on Microsoft
 operating systems. There are other deficiencies that I think are probable,
 but we won't know until we get to play with it.

 I definitely intend to keep plugging away at FOP.

 Victor Mote

Victor, I intend to continue supporting FOP myself.

But can I point out that C is about as portable as it gets?

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

 -Original Message-
 From: Victor Mote [mailto:[EMAIL PROTECTED]]
 Sent: December 14, 2002 3:40 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Sun XSL Formatter


 Arved Sandstrom wrote:

  But can I point out that C is about as portable as it gets?

 Maybe someone on this list has time to throw xmlroff source code
 into Visual
 Studio  let us know how it goes :-)

I'll probably do just that. If it was well-written code then it'll compile.
There is nothing OS-specific about XSL, barring optimizations.

 Sorry, I don't mean to be smart. It certainly seems to me that
 C-portable is
 an entirely different concept than Java-portable.

Sure, in a narrow sense. Binary rather than source. In practical terms C is
considerably more portable. Java is basically a Windows and MacOS X VM.

 Also, I didn't intend to /only/ highlight portability. Java has lots of
 other advantages over C that are important to this kind of application. I
 won't recite them here, since everyone on this list already knows them.

We could debate that. :-) I spend a lot of time every week dealing with Java
NPEs.

Seriously, you're right. Java is better for this. Writing good C requires a
lot of background.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

 -Original Message-
 From: Tony Graham [mailto:[EMAIL PROTECTED]]
 Sent: December 16, 2002 12:23 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Sun XSL Formatter


 Arved Sandstrom wrote at 14 Dec 2002 15:05:05 -0400:
   No bitterness at all, actually, Peter. It takes a bit of wind out of my
   sails, sure, since xmlroff is so similar to the project that
 Eric Bischoff
   and myself were working on. Tony has certainly been aware of
 that for quite
   a long time - I don't understand why the secrecy, myself,
 seeing as how we
   are now looking at an OSS donation anyway.

 Sun policy, not personal policy.

 I assure you that there are many steps, and many signatures, required
 when a large corporation makes an open source donation.  Purely
 because it is a large corporation making the donation and not an
 individual contributor, there is a lot of due diligence to be done.
 If a project can't pass all the criteria, it won't be made public.

 Since a project intended for open souce may not make it to open
 source, it is perhaps better to say nothing until the due diligence is
 completed (or, in this case, very nearly completed).  The alternative
 -- announcing an intention to make a public source donation -- risks
 the project not passing the criteria and risks later accusations of
 vapourware or accusations of lack of commitment to open source when
 the project can't be made public.

 That's why I couldn't say anything about the formatter in the lead up
 to XML 2002: any of a number of people -- not just engineers and
 engineering managers -- could have vetoed the donation for any of a
 number of reasons, and I would have just had to withdraw from the
 conference without another word being said.

I actually know that. I was just blowing off steam. :-)

   I'd be bitter if I were so arrogant as to think of myself as
 being upstaged.
   :-) That's not the case. I am quite familiar with the spec,
 and there are
   now a number of competing efforts. None of which are quite accurate. So
   there is room for more competition. Alternatively, I may talk
 to Tony and
   Eric and see if we can assist.

 Part of why it is written in C is so it doesn't compete with FOP for
 developers.

 Arved took the wind out of my sails for a while when he announced his
 SourceForge project, so wind taking runs both ways.  I would be
 pleased if Arved and/or Eric would consider assisting with the
 project.  Frankly, I would be pleased if *anybody* assisted with the
 project, but Arved and Eric would be a bonus.

Eric will have to weigh in himself. I think he is partial to C++. I am
partial to C, and said that earlier this year; it was my original intention
to go with C.

I've been dormant on xslfoproc for a while; work has not permitted much OSS
for me at all. I may have time coming up; it would be a pleasure to help
out. I also concur that it would be nice to have Eric involved.

I see no reason for competition. A single decent open-source C or C++
implementation would be great.

Incidentally, my comments about potentially having had to consider the
adoption of this project into Apache still stand. It is no reflection on the
project, or on you, Tony. It is a personal philosophical stance - yes,
company donations have provided the ASF with fine software, but there is a
downside.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Sun XSL Formatter

[Arved Sandstrom]

But it was plausible. :-)

 -Original Message-
 From: Patrick Dean Rusk [mailto:[EMAIL PROTECTED]]
 Sent: December 18, 2002 12:51 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Sun XSL Formatter


 Then I retract the suggestion.

 Pat


 -Original Message-
 From: Tony Graham [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, December 18, 2002 8:36 AM
 To: [EMAIL PROTECTED]
 Subject: RE: Sun XSL Formatter


 Patrick Dean Rusk wrote at 17 Dec 2002 17:40:11 -0500:
  Perhaps Tony knows better, but I have a potentially plausible
 explanation
   for Sun being secretive about their project:  it may not
 initially have
   been intended for eventual open source development.  In other words, it
   could be a failed internal project to create a commercial product.

 No.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Overconstraint Anomalous documents page in Wiki

[Arved Sandstrom]

Title: JforIntegrationInFop - background and guidelines



I 
looked at the page, Rhett. It looks good as a mission statement. This area 
interests me a lot too, and I hope to start adding to it.

Arved

  -Original Message-From: Rhett Aultman 
  [mailto:[EMAIL PROTECTED]]Sent: December 26, 2002 2:39 
  PMTo: [EMAIL PROTECTED]Subject: Overconstraint 
   Anomalous documents page in Wiki
  Foppers,
  
  I've 
  added a page to the Wiki in an attempt to put all of our previous discussion 
  and what documentation I can find regarding overconstraint, anomalous 
  documents, etc. It's located at:
  
  http://nagoya.apache.org/wiki/apachewiki.cgi?FOPOverConstraintDesign
  
  I'd 
  like to make this part of a general documentation of layout design in general, 
  and hope to be a strong facilitator in its development on the Wiki. I 
  welcome anyone who's had anything to say about overconstraint or other 
  anomalous conditions in the past to start putting their ideas up on the 
  page. With a little work, I think we can start incorporating a design 
  for overconstraint resolution into the HEAD layout managers. I see the 
  rudiments of that system already forming, so I think we've got a good starting 
  point.

RE: Footnote Problem

[Arved Sandstrom]

 -Original Message-
 From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: January 3, 2003 5:53 PM
 To: [EMAIL PROTECTED]
 Subject: Footnote Problem
 
 
 Hi all,
 is the footnote are supposed to span the whole page width even
 if the body region has columns? If so, adding a footnote would
 cause reshuffling of content of already filled columns, which in
 turn might push the FO causing the footnote onto the next page
 (another candidate for the anomalous layout wiki?).
 Apart from this, is this case similar enough to rebalancing in
 case a fo:block span=all is encountered?

Yes. There is no provision for columns in the footnote region.

Arved

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

Joerg, you can freely get rid of that stuff. I originally introduced it when
I had more faith in the spec, and thought that the authors knew what they
were talking about when it came to to their math. Specifically, the lineage
pairs is an abstract concept that I can see no implementation use for. In
fact, I can't see any theoretical use for the idea either.

Arved

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: February 16, 2003 8:14 PM
 To: [EMAIL PROTECTED]
 Subject: Markers in areas


 Hi,
 does somebody need the markers attached to an area? I just canned them,
 as well as another array atteched to areas (lineage pairs). Markers
 were only used in the XML renderer. They ought to have uses to implement
 retrieve-positions first-include-carryover and last-ending-within-page,
 but they didn't get used for this.

 Objections?

 J.Pietschmann


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

They are not connected concepts, Mark. I originally put in the code for
lineage pairs, and also started the implementation for markers. So I can
assure you that they are completely unrelated. For what it's worth,
subsequent contributors have significantly improved on marker support, so I
am only commenting from the viewpoint of my knowledge of the spec.

I made a few comments in my reply to Joerg. I have a degree in physics, and
most of a Masters in physical oceanography. I see considerable mathematical
anarchy in the XSL spec, some degree of mathematical naivete, and lots of
confusion. My forte is not logic, based on my background, but even a physics
guy can dissect the pseudo-logic in that spec. I think plenty of other
people have also separated the wheat from the chaff as far as that document
is concerned...I think we are due for a rewrite, with lots of the
pretentious math excised, and replaced with plain language.

Arved

 -Original Message-
 From: Mark C. Allman [mailto:[EMAIL PROTECTED]]
 Sent: February 18, 2003 5:16 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Markers in areas


 ... but markers will continue to work as per the XSLFO spec, correct?
 We depend on markers for dynamic page headings.

 -- Mark C. Allman
 -- Allman Professional Consulting, Inc.
 -- www.allmanpc.com, 617-947-4263


 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, February 18, 2003 4:09 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Markers in areas

 Arved Sandstrom wrote:
  Joerg, you can freely get rid of that stuff.

 Great!
 Anybody out there bothering to profile the new code? Two
 objects less created per Area, this should be noticable!

 J.Pietschmann


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Long licence

[Arved Sandstrom]

Dirk, you may have seen my post on members, about this. The whole length of
license issue.

I find it odd that it's OK to suggest tools (IDEs/editors, etc) to hide a
license. When the argument presented to the board was presumably that the
long license is legally required.

I'd like to find out what lawyer thought a long license is needed with every
file. Because I question that finding.

Arved

 -Original Message-
 From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]]
 Sent: February 21, 2003 8:43 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Long licence

 On Fri, 21 Feb 2003, Jeremias Maerki wrote:

  software developers. :-) It would be so cool, if IDEs would have the
  ability to hide a licence at the beginning of a file.

 I;ve seen some clever pragma's/markers which let emacs do this.

 DW


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Long licence

[Arved Sandstrom]

Jeremias, a deliberate decision was taken to frown on condensed licenses or
references. That tell me that there is a legal requirement for the license
to be in your face. So to speak.

In any case, the board was presented (I assume) with a legal opinion to that
effect. Which, although IANAL, I dispute.

If it so happens that I am wrong (it's been known; I was last wrong on
October 14th, 1995), I am sure that someone will so inform me. But I am
checking with some local IP lawyers to see what the deal is.

My point being that legally there is no distinction between developers
working with OSS, and any other users. And in fact the distinction ought not
be made, as many of the same developers _are_ users of the codebase. So it
is OK to hide the licensing? I think not.

I dislike a long boilerplate license. There are two ways to get rid of it -
one is to use technological techniques to ignore it. I don't like that. FOP
for example has many hundreds of source files...tack in a screen of legal
stuff with each one and note that people with dialup just got presented with
some extra download time. Significant extra download time.

I intend to clarify this issue on the ASF members list. I have problems with
this decision.

Arved

 -Original Message-
 From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
 Sent: February 21, 2003 9:19 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Long licence


 Arved,

 I don't see what's bad about it. The licence stays in every file as
 necessary, the IDE should just as a service to the developer hide the
 licence because it's not relevant to normal development tasks.

 On 21.02.2003 14:01:34 Arved Sandstrom wrote:
  I find it odd that it's OK to suggest tools (IDEs/editors, etc)
 to hide a
  license. When the argument presented to the board was
 presumably that the
  long license is legally required.


 Jeremias Maerki


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

Well, Peter, no, I haven't written something this direct - yet. My trust in
their responsiveness is at an ebb; they don't answer much communication, of
any nature, quickly, so I doubt that they will answer a more critical email
at all.

FWIW I consider all of the editors to be way more experienced than me, when
it comes to documents, and publishing, and so forth. I don't equate that
with expertise in math, or programming, or technical writing. Number one,
trained technical writers should write technical docs - a whole bunch of W3C
recommendations prove that. _I_ am not very good at writing technical docs;
I get windy and abstruse. That's why I don't get paid to write docs. :-)

Every XSL-FO implementation has a different treatment of
reference-orientation. I keep harping on this, I know. In fact, I think
_my_ interpretation is correct, and almost everyone else is wrong. I think
that because I read the English in the spec. I know that sounds arrogant,
but I have told the editors before that I'll implement according to the
letter, not the spirit. If they wish to argue that the language says
differently than what I think, that's their prerogative.

There is a better procedure for turning out specs. The W3C hasn't twigged.
Good companies in the industry already know it. It's invite the
customers/clients in, get them to hash things out with the programmers and
technical writers, and then let the latter two groups turn out a good
document, or a good implementation. Or both. In this case the experts are
the customers; we have a confused spec because they thought they were the
programmers and writers as well.

Arved

 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]
 Sent: February 22, 2003 8:23 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Markers in areas


 Arved Sandstrom wrote:
  They are not connected concepts, Mark. I originally put in the code for
  lineage pairs, and also started the implementation for markers. So I can
  assure you that they are completely unrelated. For what it's worth,
  subsequent contributors have significantly improved on marker
 support, so I
  am only commenting from the viewpoint of my knowledge of the spec.
 
  I made a few comments in my reply to Joerg. I have a degree in
 physics, and
  most of a Masters in physical oceanography. I see considerable
 mathematical
  anarchy in the XSL spec, some degree of mathematical naivete,
 and lots of
  confusion. My forte is not logic, based on my background, but
 even a physics
  guy can dissect the pseudo-logic in that spec. I think plenty of other
  people have also separated the wheat from the chaff as far as
 that document
  is concerned...I think we are due for a rewrite, with lots of the
  pretentious math excised, and replaced with plain language.

 Arved,

 Hear, hear.  Arved, have you told the editors this directly?  If not,
 please do.

 --
 Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
 Lord, to whom shall we go?


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Long licence

[Arved Sandstrom]

 -Original Message-
 From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]
 Sent: February 21, 2003 1:35 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Long licence

 On Fri, 21 Feb 2003, Arved Sandstrom wrote:

  I'd like to find out what lawyer thought a long license is
 needed with every
  file. Because I question that finding.

 Question the board (again) for a black/white answer - or work with
 licensing for a more interactive reply.

Point taken. I get too much email already, so I've been averse to joining
more lists. Maybe in this case I should join another.

 But Bear in mind that the current 'license' is more than just strictly a
 license; it contains elements of copyright, waiver and an agreement.

Understood.

 Bear in mind that the answer to vague questions like that carry very
 significant price tags; and are very depended on the exact question; which
 itself by its very nature is inexact.

Yes. It's our business to pose the exact questions. It's the business of the
lawyer to supply an answer.

FWIW, I am not vilifying lawyers. My older sister is one. :-)

I feel like the right questions weren't asked.

 Also bear in mind that there are very, very few layers who actually have
 studied open-source licenses in sufficient dept; and that most answers
 from case-law are about proprietary and protectionist stances; and often
 very US specific; and may be very dated.

Yes, I agree.

 Also bear in mind that the answer differs from jurisdiction to
 jurisdiction; and from how litagationous/defensive the side you want to
 err on is.

Well, I differ from our US friends on this. I prefer to be terse and clear,
and maintain some trust in people.

 Finally bear in mind that the board propably does not want to ask
 expensive questions now with respect to the current license; as the new
 license is not far off - and the new license has taken into account this
 desire to include by reference.

OK, fair enough. I'll wait to see it.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

Hi, Keiron

I interpret 6.11.4 as follows. Number one, the names have to match -
marker-class-name and retrieve-class-name. This is straightforward. It
defines qualifying areas.

Number two, qualifying areas are excluded if they follow the page being
formatted, regardless of retrieve-boundary. So retrieve-boundary
essentially defines the backward limits. Finally, retrieve-boundary also
restricts qualifying areas in the backward direction: page says that if
it's not on the currently being-formatted page, it isn't up for
consideration.

For last-starting-within-page, is-first is clear enough I think. An FO
is generating and returning areas on the containing page, and the first one
is...well, the first one. :-) So it is the optimal candidate if its parent
FO has qualifying markers. With reference to your [2], return to the def'n
of qualifying area: name-matching, period. I assume last in this context
means last geometrically, as opposed to some other last. Eg, immediately
preceding as one normally reads a document.

I think whoever wrote this portion (markers) made the spec too abstruse. I
finally just broke my rule of adhering to the law, and considered the use
cases, and decided what made sense. :-)

Arved

 -Original Message-
 From: Keiron Liddle [mailto:[EMAIL PROTECTED]
 Sent: February 23, 2003 6:49 PM
 To: [EMAIL PROTECTED]
 Subject: Re: markers in redesign


 Hi all,

 Is it correct that it should look for markers on the current page
 and if page
 boundary is current page then stop there. If boundary is
 page-sequence then
 keep going backwards on each page until a marker is found or
 reaches the start
 of the page-sequence and similarly for the document boundary.

 I'm trying to work out exactly how the markers should work.
 For the first starting within page and last ending I am fine
 with. First including
 carry-over seems okay.

 Last starting within page is a bit confusing. A statement [1] in
 the spec suggests
 that it shouldn't really find the last starting in the page but
 rather find the closest
 node to the root in the area tree that is the last starting area.
 Another statement [2]
 seems confusing but maybe this is if it is searching previous pages.

 So if this was in a page then block a would be the last
 starting in the page.

 -start--
 ...
 block id=a
   block id=b
   /block
 ---pos1-
   block id=c
   /block
 /block
 end---

 But if there is a column break in pos1 the last starting in page
 will become
 block c as block a is not starting in that part of the area tree.

 If this is the case then there are two possible cases when
 starting an area: isfirst
 and other. When finishing an area there are: islast, (had)
 isfirst and both. This will
 supply enough information to add only the needed markers to the
 area tree. These
 markers can then be kept for later retrieval.

 [1] Every area in the hierarchy is considered preferential to,
 or better than, any
 area below it in the hierarchy.

 [2] If there is no such area, then the last qualifying area in
 the containing page is
 better than any other area.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

Comments below.

 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]
 Sent: February 24, 2003 6:53 AM
 To: [EMAIL PROTECTED]
 Subject: Re: markers in redesign

[ SNIP ]

 It seems to me that the hierarchy is not the same as the area tree or
 fo tree hierarchy.  It is a unique hierarchy constructed by applying the
 constraints on the qualifying areas.  The boundary conditions impose
 absolute constraints - violate one and you are out.  But the other
 conditions are not absolute, and they, along with actual page for
 multi-page boundaries, are used to construct the hierarchy.

Yes, that's my interpretation. Precisely so. It is tempting to confuse
hierarchy for tree. But the language of the spec in regard of markers
defines a different hierarchy, one which happens to map closely to the area
tree, but is highly filtered.

I re-assert that in the case of this particular section of the spec, we can
fall back on common sense, although normally I am loath to do so (it may
sound funny to hear that, but I am a professional software developer, and
I'd rather follow the letter than the spirit. That approach usually assures
better code, and better specs). That means to me that in this case we use
the use cases in the spec to identify what makes sense. Markers are amenable
to this, as opposed to reference-orientation, because the latter is an
artificial concept, and several interpretations may apply.

That means, to me, first, that we use the naming to identify qualifying
areas.

Two, we use retrieve-boundary to filter out qualifying areas. I make that
distinction, because qualifying areas are defined by the naming alone.

Three, we use retrieve-position coupled with area traits (and the traits
are easy to establish) to figure out the best qualifier on the _current_
page.

The thing that bugs me is, when there is no qualifying area in the
containing page (Note to spec editors: try saying currently-formatted
page), after filtering, then it becomes anarchy. It seems like user
preferences based on retrieve-position lose all relevance. In other words,
there is an elaborate set of definitions based on the current page, with a
hierarchy defined by retrieve-position, but as soon as one establishes
that there is no such qualifying area on the current page, than it's just
the first qualifying area one can find, moving back in the document.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

Comments inline.

 -Original Message-
 From: Tony Graham [mailto:[EMAIL PROTECTED]
 Sent: February 24, 2003 10:26 AM
 To: [EMAIL PROTECTED]
 Subject: RE: markers in redesign


 Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400:
   Comments below.
  
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
Sent: February 24, 2003 6:53 AM
To: [EMAIL PROTECTED]
Subject: Re: markers in redesign
   
   [ SNIP ]
  
It seems to me that the hierarchy is not the same as the
 area tree or
fo tree hierarchy.  It is a unique hierarchy constructed by
 applying the
constraints on the qualifying areas.  The boundary conditions impose
absolute constraints - violate one and you are out.  But the other
conditions are not absolute, and they, along with actual page for
multi-page boundaries, are used to construct the hierarchy.
  
   Yes, that's my interpretation. Precisely so. It is tempting to confuse
   hierarchy for tree. But the language of the spec in regard
 of markers
   defines a different hierarchy, one which happens to map
 closely to the area
   tree, but is highly filtered.

 It's not just areas.  fo:wrapper 'does not generate any areas', but
 also 'may always have a sequence of zero or more fo:markers as its
 initial children.'

No, you're quite right, Tony, fo:wrapper does not generate areas. But it
_returns_ areas, assuming that its children do (there are presumably some
pathological cases), and those areas are what markers act on. wrapper is
transparent.

I may have missed your point on this.

 ...
   The thing that bugs me is, when there is no qualifying area in the
   containing page (Note to spec editors: try saying currently-formatted
   page), after filtering, then it becomes anarchy. It seems like user

 I wasn't there when the spec was written, but it seems to me that
 'currently-formatted page' presupposes making pages on the fly and
 doesn't quite describe pages that are unbounded in one or both
 directions (i.e. where there is only ever one page) and also doesn't
 describe the possible processing model of making all the pages from
 the fo:flow and then going back and fixing up the static content.

OK, you've got me here. :-) I fall into the trap of ignoring media-usage
too frequently. So the point is well taken.

Regarding the second point, that processing model ignores an
error-if-overflow value for overflow; process a thousand pages and then
only afterwards find out that you ought to have aborted with a message?

Regards,
Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

Comments below.

 -Original Message-
 From: Keiron Liddle [mailto:[EMAIL PROTECTED]
 Sent: February 24, 2003 10:59 PM
 To: [EMAIL PROTECTED]
 Subject: Re: markers in redesign

  Exactly. All definitions regarding retrieve-position exclusively
  refer to the current page. There is not a single word on what should
  happen if there is no matching marker on the current page but several
  on the previous page which are eligible. FOP picks the last, but there
  is absolutely nothing in the spec which backs this, and I searched
  thoroughly last weekend.

 For the current page or containing page I take it to mean like so
 (assuming doc or
 page-sequence boundary):
 If we are on the third page of a document and we want to retrieve
 a first-starting-
 within-page then it will look on page 3, if it finds the marker
 then fine. If not then
 there is no such area (on the current page) and it should look at
 page 2. Page 2 is
 now the containing page and it looks for a marker that is
 first-starting-within-
 page on page 2. Then page 1...
 Admitedly it doesn't actually say that, but I can't interpret the
 wording otherwise.

[ SNIP ]

I re-read the spec so exhaustively that my eyes are burning. :-) I think
Keiron is right.

Boy, it would be cool if they could rewrite that section, though. :-)

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

 -Original Message-
 From: Keiron Liddle [mailto:[EMAIL PROTECTED]
 Sent: February 25, 2003 9:16 PM
 To: [EMAIL PROTECTED]
 Subject: Re: markers in redesign


  Looking at it again, I disagree.  The containing page is the page
  containing the first area generated or returned by the children of the
  retrieved fo:marker.  That is, the page on which the fo:retrieve-marker
  occurs in the static-content.  This will only vary if the retrieval
  forces a re-layout.

 How do you jump from the first sentance to the second one. The
 containing
 page refers to the page where the marker is first formatted not
 where the
 retrieve-marker occurs.

That's now my opinion also, after my re-read. I made the other assumption
based on the obfuscated language.

 I vote for a clarification and a re-write, the containing page is
 defined by the
 retrieved marker, the marker to retrieve is defined by the
 containing page.

I think we can all agree on asking for a rewrite. :-)

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Information on who's leading FOP

[Arved Sandstrom]

Hi, Gaurav

To add to Jeremias' reply, which is accurate, might I add that there are in
fact leaders when it comes to ASF projects? Jeremias is one himself.

To be less vague, let me expand by saying that there are committers who are
interested in the codebase only, and then there are committers who are
interested in more - documentation, planning, the community, etc. The former
category, just as the non-committer developers, is not to be denigrated, but
you can defintely identify committers who take an interest in the big
picture as leaders.

Arved Sandstrom

 -Original Message-
 From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
 Sent: March 11, 2003 6:24 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Information on who's leading FOP


 Projects at Apache don't work this way. No boss and underlings. The
 list of people you found are most probably the committers. They run the
 project.

 Here's some more information:
 http://xml.apache.org/whoweare.html
 http://incubator.apache.org/drafts/theapacheway.html

 I hope that helps. If you need more information just call for help.

 On 11.03.2003 23:13:30 Gaurav Pal wrote:
  I'm working on a project that will be using FOP as a report generator.
  While trying to sell the idea to the senior management, I was asked to
  find out who's leading this effort at Apache.
 
  I searched the FOP web site and also the mailing list archives but didnt
  find anything. There are a number of developers whose names I got from
  the mailing lists but no information on who is the lead.
 
  I'd appreciate it if someone could give me this information or point me
  to where I could find it.


 Jeremias Maerki


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Nomination of Glen Mazza as committer

[Arved Sandstrom]

 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]
 Sent: June 16, 2003 5:46 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Nomination of Glen Mazza as committer
 
 
 Victor Mote wrote:
  Being the greenest committer, I had hoped to defer this 
 nomination to a more
  senior developer. However, I think it is appropriate to 
 nominate Glen Mazza
  for committer status. He is knowledgeable and thoughtful, and I 
 think it is
  in the interest of the project to turn him loose so that he can 
 keep working
  without having to wait on us.
 
 +1

And also +1.

Arved

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Place committers on inactive list?

[Arved Sandstrom]

 -Original Message-
 From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
 Sent: September 2, 2003 2:49 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Place committers on inactive list?


 Le Mardi, 2 sep 2003, à 03:33 Europe/Zurich, Glen Mazza a écrit :
  ...Perhaps Karen, Arved and Bertrand should be added to
  the inactive list...

 No problem for me, I'd actually feel better being listed as inactive!

That would be realistic. I have no intentions of permanently leaving the
project, but I have been inactive for quite some time. I am just too busy in
other pursuits at the moment.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Development Environment suggestions ?

[Arved Sandstrom]

 -Original Message-
 From: John Austin [mailto:[EMAIL PROTECTED]
 Sent: November 20, 2003 12:37 PM
 To: [EMAIL PROTECTED]
 Subject: Development Environment suggestions ?

 So far I have been playing around like the Neanderthal*
 that I am. I use Sun Java 1.4.x with xterm, vi, emacs and
 occasionally Jedit when I feel modern urges.

 Peter has mentioned Eclipse and I have used VisualAge for
 Java, and either NetBeans or the Sun form thereof.

If you have a few bucks, you can't beat IntelliJ IDEA. I have used VisualAge
and NetBeans, and also JEdit, vi and emacs, but IntelliJ has them all beat
hands down.

 Is there a path to enlightenment (excuse the trollish tone)
 therein ? Given that FOP can be installed and started in
 TBI (The Bash IDE), are there other graphical IDE's with a
 reasonable learning curve ?

IntelliJ is fairly easy to pick up.

 I have both Win98 and RH9 available to me. The RH box
 has more resources in addition to having the usual Linux
 advantages.

As another poster mentioned, upgrade from Win98. Win98 has limited GDI
resources (that is, the amount of memory for actual windows, visible or
invisible), so is a PITA for serious development.

 * Is that term Politically Correct ?  Would it be offensive to
 Europeans ? I myself am descended from Celts and probably
 some Angles, Jutes and Saxons. Dunno about Picts.

As I understand it, Neanderthals were as smart as us Cro-Magnons. :-)

AHS