Re: help!!!

[Peter B. West]

It's being done.  Look for xslfo-proc on sourceforge.  And look for a
new boss.

Peter

>   I using JAVA only one year!
> 
>   My boss order me analyse FOP,and rewrite in C++;I think it's impossible!

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


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

Re: JDK 1.2 containers in maintenance branch

[Peter B. West]

Joerg,

For major changes like this, it would be a good idea to tag the tree 
before committing.  The easiest way, probably, is to get ask someone 
else with a current version to update and tag before you commit.

Peter

J.Pietschmann wrote:
> Hi all,
> I've replaced most of the JDK 1.0 containers by 1.2 containers
> in the maintenance branch, ready to commit. The PDF produced
> from FOP examples compares ok with PDF produced before the
> conversion. I might have screwed up other renderers, in
> particular the MIF renderer which required quite a bit more
> than a simple S&R. I might also have produced additional
> MT problems, even though I set FOPImageFactory to synchronized.
> 
> If there are no vetoes, I'll commit the change on 2002-08-02,
> 21:00 CEDST.

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


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

Redesign vs. maintenance branch

[Peter B. West]

Joerg,

I've agreed before with the importance of incremental improvements to 
the existing base.  However, Keiron has been the strongest supporter 
here of the principle of working from the existing base.  His work on 
the redesign is based, I believe, on his understanding of the existing 
design, his (and others') efforts to fix the problems over a long 
period, and his (and others') reluctant conclusion that some new design 
paradigms were necessary.

Do you believe Keiron's understanding to be false?  Do you believe that 
the same result can be achieved by incremental improvements?  If so, you 
may ignore the redesign efforts in good conscience.  If your conclusions 
are not so radical, then it seems to me that, when making major changes 
to production, you ought to make all reasonable attempts to keep changes 
in the production branch in sync with the redesign.  Your comment about 
the worrisome things that are still in the redesign underlines this.

Evidently, that means more work.  But before the redesign goes live, 
those changes are going to have to be made anyway, and that work will be 
particularly onerous if it has to happen all at once, rather than 
piecemeal by the person who writes the changes.

Given all of the above, "stealing" code from the unfinished redesign for 
the maintenance branch, to quote Jeremias, would be essential to make 
synchronisation in the other direction feasible.

Peter

P.S. As it happens, I agree that HEAD should represent the production 
code, and that development should take place on a branch.  In this case, 
though, it would probably just facilitate the isolation of the redesign.


J.Pietschmann wrote:
> Jeremias Maerki wrote:
> 
>> I'm not so happy about this one. I know I'm also guilty of doing more
>> work for the maintenance branch than for the redesign, but "stealing"
>> code from the unfinished redesign for the maintenance branch seems to me
>> like starting to take its breath away.
> 
> 
> The problem is that HEAD does not work, and even after
> Keiron gets som block and layout out of the door, it will
> be far from ready to release.
> 
> One thing which particularly bothers me is that much of
> the odd stuff is still in the redesign. Especially it
> does not all that much to reduce memory usage, in fact
> I have the feeling it will substantially *increase* it.
> I wish this Mark Lillywhite character were still around.
> 
> While there are other projects fighting with a HEAD
> representing "new idea" stuff and a branch with "tried
> technology" for the normal users to check out, IMO it
> should be the other way around: have always a working
> version in HEAD, make branches to develop new ideas,
> and integrate them into HEAD as they mature.

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


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

Re: Correction: Leaders and leader-length in justified blocks

[Peter B. West]

pietsch,

(I've moved this part to fop-dev.)

I have just whiled away a few hours looking at this.  In terms of what 
it should do, the spec says, in 7.21.4 "leader-length"


NOTE:

User agents may choose to use the value of "leader-length.optimum" to 
determine where to break the line, then use the minimum and maximum 
values during line justification.

Leader length values such as:

leader-length.minimum="0pt"
leader-length.optimum="12pt"
leader-length.maximum="100%"

would specify constraints that would cause the leader to fill all 
available space within the current line area as part of the process of 
justifying that line area.

NOTE:

... a leader formatting object's length-range provides further 
flexibility to the justification process. Though any result that 
satisfies the specified constraints would conform to this specification, 
current typographic practice would tend to make use of leader length 
flexibility in preference to other flexibility (e.g. word spaces) within 
the same line area when justifying the line...



As I read that, the maximum value does not come into play unless and 
until the line is being justified, whether by virtue of a text-align or 
a tex-align-last.  The decision on how many fo:s fit on a line is taken 
w.r.t. the optimum.  The implication here is that there will generally 
not be a great difference between the optimum and the actual value used. 
  However, if you are constructing a series of last-lines with, say,
text...page-number
the difference is irrelevant.  It has already been determined that the 
optimum fits on the line.  The justification process then pads out the 
line from the fo:leader, according to the Note from the spec., ignoring 
word spaces.

If the code you quote is part of the line justification, it would be 
ignoring minimum because the line breaking has already found that the 
optimum will fit.

That still leaves some odd code, as you say.  The relation
  minimum <= optimum <= maximum

should always hold, and should be tested up front.  If true, the code 
above becomes

if (remainingWidth <= leaderLengthOptimum)
leaderLength = remainingWidth;
else if (remainingWidth > leaderLengthMaximum)
leaderLength = leaderLengthMaximum;

and the last condition (leaderLengthOptimum > leaderLengthMaximum) can 
never be true.  The author assumes, no doubt correctly, that the 
min/opt/max relationship cannot be guaranteed from elsewhere. However, 
that responsibility should be shifted into the basic compound handling 
code, if only to simplify code like the above.

Peter


J.Pietschmann wrote:
> Thibodeaux, Paul wrote:
> 
>> Correction - it doesn't throw in w fixed length, but it seems to use the
>> MAXIMUM rather than the OPTIMUM.
>>
>> I would have thought that it would respect the JUSTIFY and use OPTIMUM.
>>
>> Any good online explanation of how this works?
> 
> 
> How it works in FOP or how it should work?
> The implementation is in Linearea.java.
> Here is the code for computing the leader length:
>/**
> * checks whether leaderLenghtOptimum fits into rest of line;
> * should never overflow, as it has been checked already in BlockArea
> * first check: use remaining width if it smaller than optimum oder 
> maximum
> */
>if ((remainingWidth <= leaderLengthOptimum)
>|| (remainingWidth <= leaderLengthMaximum)) {
>leaderLength = remainingWidth;
>} else if ((remainingWidth > leaderLengthOptimum)
>   && (remainingWidth > leaderLengthMaximum)) {
>leaderLength = leaderLengthMaximum;
>} else if ((leaderLengthOptimum > leaderLengthMaximum)
>   && (leaderLengthOptimum < remainingWidth)) {
>leaderLength = leaderLengthOptimum;
>}
> The .minimum is not used at all.
> The code looks a bit odd, but I couldn't quite figure what
> it should look like. The wiggle room provided by leaders is
> not used for justifying the line (except for space leaders),
> only spaces are used.

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


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

Re: [PDF Viewer] Utility request

[Peter B. West]

Victor,

FOP has no control over any downstream uses of generated PDF, clearly. 
Any project that works with the PDF is logically independent of FOP, so 
it would belong in a separate project, as you suggest.  It would be 
unfortunate if folks got the idea that FOP was somehow more fully 
realised in a Windows/Mac environment.

I may be drawing a long bow in saying that x-platform accessibility is a 
basic assumption of the XML sub-projects.  It just seems to have panned 
out that way, and I'm pleased about that.

Peter

Victor Mote wrote:
> Peter:
> 
> If FOP has some obligation to support any downstream use of its output in a
> cross-platform way, then that is a pretty tall order. I guess in my mind
> getting the file into cross-platform PDF format is sufficient. I don't have
> more than an intuitive grasp of the "basic assumptions of the Apache XML
> efforts", but rendering PDFs would violate my understanding of that concept
> simply because it ain't XML (support for structure in recent PDF versions
> notwithstanding). IMHO, if it is needed at all, it probably belongs in a
> separate project. I like the proposed solution of fixing / completing the
> FOP Area Viewer much better. (Please count my newbie vote at less than 1% of
> the value of the real contributors.)

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


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

Work on HEAD

[Peter B. West]

Keiron,

It's easy for the designers to underestimate the size of the hurdle that 
potential developers must negotiate to get up to speed on a project of 
the complexity of FOP.  It would be difficult if we were all sitting in 
the same room.  Casual contributors much prefer to tinker with code that 
is already working; there's a shorter path to productive contributions. 
  If you can corral a group of interested potential developers, I think 
you will need to spend the vast majority of your time developing the 
developers, rather than the design.  Lots of very detailed and 
re-iterative design discussion, heavy use of your favourite drawing 
tools, and chat time.

I know I'm repeating myself, and I know that I am working on a design 
strand that is much farther away from the existing code than you are, 
but I would like to see the re-design go forward, and I think potential 
contributors need a lot more encouragement.

Peter


Keiron Liddle wrote:
> (One day I will convince someone to help out with HEAD code)

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


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

Re: [PDF Viewer] Utility request

[Peter B. West]

Victor,

The IAC, by this account, only has support for Macintosh and DDE/OLE on 
WIndows.  While some work on support for OLE 2 document formats has been 
done in the Jakarta POI project, I don't know that this will solve the 
problem of cross-platform support for the project you have in mind.  If 
it's not x-platform, it violates one of basic assumptions of the Apache 
XML efforts (although users without access to Java 2 may raise their 
eyebrows at that.)

Peter

Victor Mote wrote:
> Ralph LaChance wrote:
> 
> <-Start->
> Last time I used the Acrobat SDK (1999) it provided support only building a
> plug-in to Acrobat Exchange (not free) - ie. adding functionality to
> Exchange itself -- things like specialized searching, indexing, or
> retrieving simple objects (including text) from the file, adding work flow,
> modifying Exchange's menus etc. It provided NO support for rendering per se,
> and, more importantly, had almost no support for modifying the (free)
> Reader.
> 
> Whether one could use a plug-in as a vehicle for tightly bolting acrobat
> exchange is an interesting concept, but (in my opinion) we'd not have any
> chance to doing anything useful with the reader.
> <-End->
> 
> Paragraph 1, Chapter 1 of the Core_API/CoreAPIOverview.pdf document in the
> Acrobat 5 SDK doc says:
> 
> <-Start->
> The Acrobat core API is a set of interfaces you can use to write plug-ins
> that integrate with Acrobat and Acrobat Reader. This chapter introduces the
> core API, describing its object orientation and organization, and a number
> of other concepts fundamental to understanding the API.
> 
> Ways to Integrate With the Acrobat Viewers
> You can develop software that integrates with Acrobat and Acrobat Reader in
> two ways:
> * By creating plug-ins that are dynamically linked to the Acrobat viewer and
> extend the viewer's functionality
> * By writing a separate application process that uses interapplication
> communication (IAC) to control Acrobat functionality. DDE and OLE are
> supported on Windows and Apple events / AppleScript on the Macintosh.
> <-End->
> 
> There is a separate InterApplication_Communication folder containing related
> documents. Again, I haven't done it, so maybe it is all theory that doesn't
> work for the application at hand. And I don't mean to be argumentative -- it
> just seems that writing a good PDF viewer would be a big enough task that I
> would want to exhaust other possibilities before heading down that path.

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


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

Re: AW: FO to RTF

[Peter B. West]

Bertrand,

Thanks for clarifying that.  The feasibility of an XSLT transform would 
be greatly influenced by the complexity of the mappings of properties 
into RTF structures.  If the inheritance model of XSLFO had no ready 
parallel in RTF, that set of transformations would be a nightmare, I 
imagine.

Peter

Bertrand Delacretaz wrote:
> Hi Peter,
> 
> 
>>I tentatively suggested using XSLT to generate RTF a little while ago,
>>but I had no idea whether it was feasible.  The main question would seem
>>to be: is RTF a text-only format or a binary format?  Can anyone answer
>>that one for us?
> 
> 
> AFAIK, everything in RTF can be expressed with text-only characters, and it 
> would certainly be possible to convert XSL-FO to RTF using XSLT. 
> 
> Our choice to use java for the jfor converter was based on better 
> availability of programming and debugging tools.

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


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

Re: AW: FO to RTF

[Peter B. West]

Hansuli,

I tentatively suggested using XSLT to generate RTF a little while ago, 
but I had no idea whether it was feasible.  The main question would seem 
to be: is RTF a text-only format or a binary format?  Can anyone answer 
that one for us?

Peter

J.U. Anderegg wrote:
> Document formats can be layered very roughly like this:
> 
> 1. Structured documents: marked up, tagged CONTENT - document elements like
> "heading", "index entry" and even "customer address" in a specific
> application:
>   - presentation, pagination controlled by style sheets/macros, perhaps
> depending on output device/target
>   - examples: HTML, Word with templates
> 
> 2. Document formats controlling pagination
>   - examples: WordPad, XSL:FO
> 
> 3. Device dependent, paginated output streams
>   - examples: PCL, PostScript
> 
> An other view is: revisable vs. final formats
> 
> RTF at layer 1) and 2): a text generator outputs RTF. A transform from XML
> data can be implemented with XSLT. A conversion from XSL:FO might be
> realized at layer 2), but probably fail because of incompatible
> concepts/details.
> 
> RTF is the format of yesterday: better generate MicroSoft Office XML or Open
> Office XML.
> ___
> 
> PDF Java Viewer: who can do much better than Adobe? If no Acrobat Reader is
> available, output PostScript and use GhostView instead of AWT.

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


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

Re: FO to RTF

[Peter B. West]

Ramana,

To all that Keiron has said, I would add:

Talk to Bertrand Delacrétaz<[EMAIL PROTECTED]>, who is our 
resident RTF guru, and lead developer of jfor.  Having said that, I 
notice that Chris Scott, who has also posted on this thread, has also 
contributed to jfor.

The first step, it seems to me, is to map out and document the 
similarities and dissimilarities between the structure information that 
is required by FOP and RTF respectively.  If I read him correctly, 
Bertrand has indicated that the FOP use and handling of properties is a 
focus of dissimilarities.

The parser or fo tree builder is going to throw fo: object events to you 
which represent the basic structural view of FOP.  All of the fine print 
is in the attributes.  If, before you start major hacking, you have 
documented, for each flow object, the RTF structure(s) it maps into, and 
the dependencies in that mapping on other FOs or RTF structures, and 
mapped for each property applicable to an FO a corresponding mapping 
into a relevant RTF artefact, noting its impact on FO -> RTFstructure 
mappings, if any, and whether that property must be ignored or mapped 
into some arbitrary value, those who come after you will kiss your feet, 
figuratively speaking.

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


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

Re: Line breaking and Hyphenation

[Peter B. West]

Keiron,

Undoubtedly it is better to put effort into getting the new code to 
work.  However, if, at the moment, the direction of the main line of new 
code development is only really understood by you and Karen, work on 
these things by Joerg in the -maint branch may be very useful for a 
couple of reasons.  The first is actually fixing some bugs.  The second 
is that it will give him (and others who might want to join in) a much 
better idea of the problems that the new design is trying to solve.

As here, you can indicate, before he gets involved, which areas are 
going to be superceded and which he should therefore be cautious about 
getting too involved in.  The end result may be that Joerg gets up to 
speed in the redesign as part of that process.

In any case, it is probably encouraging for our users to see that there 
is bug-fixing activity going on in addition to redesign.

What say you?

Peter

Keiron Liddle wrote:
> These (and other) problems are precisely why certain areas have been
> redesigned.
> Wouldn't it be better to put the effort into getting the new code to
> work?
> 
> On Wed, 2002-07-03 at 10:57, Joerg Pietschmann wrote:
> 
>>I put a StringBuffer into FObjMixed to accumulate
>>consecutive addCharacters() events.
> 
> 
> This is probably a good idea in general. Sometimes the SAX events can
> split text in all sort of places and it would be easier to handle if all
> consecutive text is joined together.
> 
> 
>>Questions:
>>- Is it still worth to do major hacks in LineArea.java?
> 
> 
> If you want to get rid of all the bugs, I would say no.
> 
> 
>>There are additional issues with consecutive spaces which had
>>been discussed here already, in particular how
>>  foo  bar
>>should be handled. Will this result in two consecutive spaces,
>>one of them underlined? Has this issue been resolved meanwhile?
> 
> 
> IIRC the space in the inline is "marked" and therefore this space is
> retained while the other space is discarded.

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


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

CVS problems

[Peter B. West]

Devs,

Is anyone else experiencing cvs acces problems?

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


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

Re: FOP Specialized Classloader: Request for Help #10379

[Peter B. West]

Rhett,

The way it seems to work is that the bug remains assigned to fop-dev, 
and anyone who want to add comments or attachments can go ahead. 
Consider it assigned to you.  Keep the list in touch with what you are 
doing; think aloud about design issues and ask any specific questions as 
they arise.  Most of us are working on particular areas, so you may not 
see any immediate responses, but if you keep us aware of what you are 
doing, folks can jump in with specific suggestions or objections.  Don't 
be afraid to ask specific questions, and to ask them again if the 
answers aren't clear to you, or are non-existent.  The initiative on 
this one is with you.

Peter

Rhett Aultman wrote:
> Done, and I hope I submitted it properly.  I think I did.  :)
> 
> I'm happy to have that one set as assigned to me.  If anyone else feels like jumping 
>in on this issue, too, that's great.


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


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

Re: FOP Specialized Classloader: Request for Help (Was:RE: Fop andJDK1.2)

[Peter B. West]

Rhett,

Sorry it has taken me so long to get back to you on this one.  In order 
that this not slip completely through the cracks, please put a request 
for enhancement (RFE) in Bugzilla.  You can pretty much copy your 
comments from this message into the RFE.  If you have had any further 
thoughts on the matter, generate attachment to the RFE detailing them. 
If you have used bugzilla before, you will know what I mean.  If not, 
take a look and refer any questions back here or to me.

Peter

Rhett Aultman wrote:
> Comments below.
> 
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> 
> The discussion has thrown up some interesting points, and I hope to see 
> Rhett get involved in this soon.
> 
> I hope also that the work Rhett is talking about will give us a solid 
> framework for changes to our support framework, both with the JVM and 
> possibly with the frequently changing jars that we bundle.  There may be 
> other initiatives happening within Apache on that front.
> 
> 
> 
> I think a multiplexing classloader would give us a really serious boost with regard 
>to flexibility.  This is going to be an extremely important issue not only as JVM 
>versions become more important, but also as the differences between each vendor 
>interpretation of the VM becomes apparrent.  By supplying a classloader that can, 
>based on various properties, deduce the correct class to load, we can keep FOP's 
>implementation disentangled from most of these concerns.
> 
> The actual act of selecting the correct location for loading a class is really not 
>that hard, but a classloader that makes decisions for FOP is something that's going 
>to also need someone with good experience in FOP development.  Currently, that person 
>isn't me.  I think that maybe if I and someone who's a more core FOP developer could 
>get together in private email we could get a good structure for this classloader 
>hammered out.  From there, implementation of it would be pretty easy for me to handle.
> 
> So, is anyone game?  Like I said, I can write it, but if I design this thing in a 
>vacuum, it may not be nearly as good as it could be.

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


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

Re: documentation for the maintenance branch

[Peter B. West]

Joerg,

Joerg Pietschmann wrote:
> "Peter B. West" <[EMAIL PROTECTED]> wrote:
> 
>>Obviously there is a need for some documention with normal releases.  We 
>>don't need the design docs in the user releases, but all of the 
>>operational material, including the FAQs, is necessary.
>>
>>If we were to do source and compiled releases, the xml-docs could go 
>>into the source release, for generation by the user.  Vice versa, the 
>>generated html (and pdf docs?)
> 
> +1 on omitting the design doc completely in bin distributions.
> Should probably omit skin source and xsl too.
> I'm not sure about PDF, apparently there are not much requests
> for this format.

I think html is more generally useful for user support documentation. 
It would be much, much preferable to keep html and exclude PDF than the 
reverse.

> What's larger:
> - PDF
> - xdocs +  *2document.xsl + document2fo + build mechanism for building PDF
>   (includes ant.jar?)
> - xdocs + full xsl + build mechanism for building PDF
> This may need some explanation: We have documents using a generic
> document.dtd and some documents liks FAQs which have to be
> transformed into document.dtd xdocs before the final skin
> document2html.xsl can be applied. When using ant for building,
> this requires either temporary files (current solution) or a
> custom task for the transformation pipelines (or Cocoon CLI)
> 

Is this xsl part of Forrest, or something you have done?

> 
>>need to be included in binary releases 
>>(with the proviso above, that the design docs are not needed.)  It looks 
>>as though reworking is needed in the build.xml to accommodate these 
>>distinctions.  How does that sound?
> 
> 
> That's exactly what I'm currently doing, the HTML and the
> intermediate document-DTD files are produced in the build
> directory. Unfortunately, as I already noted, it's an
> all-or-nothing thing unless you are comfortable with broken
> doc builds for some time.
> If this is ok, I can commit the first half tomorrow...


I think we can live with it.  (quietly... a working branch is very handy 
for this sort of thing...)

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


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

Re: Licence short or long

[Peter B. West]

Hi Chunk,

Yes, that does parse better, although the peculiarities of the ASF 
structure are beyond me, I'm afraid.  One day I must do some serious 
study.  Thanks for following up on this.

Peter

Arved Sandstrom wrote:
> Well, if by "ASF" you mean the board, then that sentence parses better.
> Because a mini-chunk of the ASF is already here and as uninformed as the
> rest. :-)
> 
> Seriously, though, I'll track down board minutes and see where this is
> explained, and report back.


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


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

Re: documentation for the maintenance branch

[Peter B. West]

Fopdevs,

Obviously there is a need for some documention with normal releases.  We 
don't need the design docs in the user releases, but all of the 
operational material, including the FAQs, is necessary.

If we were to do source and compiled releases, the xml-docs could go 
into the source release, for generation by the user.  Vice versa, the 
generated html (and pdf docs?) need to be included in binary releases 
(with the proviso above, that the design docs are not needed.)  It looks 
as though reworking is needed in the build.xml to accommodate these 
distinctions.  How does that sound?

Peter

Christian Geisert wrote:
> Hi,
> 
> The documentation is maintained only in the main branch (does
> everybody know this?)
> 
> For the RC I just copied the docs from the main branch and
> created the archives manually. For the final release I wanted
> to have everything in one place (merge docs from trunk into
> maintenance branch) but the problem is that stylebook needs
> xerces1 which has been replaced with xerces2.
> The question is if we should bring xerces1 back or just copy
> the docs over (and tag the main branch with fop-0_20_4-doc)
> for the release?
> 
> As Keiron already suggested (I had the same thoughts) I think
> we should remove xml-docs (and design) from bin distribution.
> I'm not sure about removing html-docs from the src distribution.
> 
> Should we remove the docs completly from the maintenance branch?
> 
> PDF generation of the documentation seems to be broken.
> 
> What is the status of the new FAQ?
> 
> Christian
> 

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


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

Re: Licence short or long

[Peter B. West]

Which means, I suppose, that we do nothing until we receive official 
notification from the ASF.

Peter

Jeremias Maerki wrote:
> Arved
> 
> I totally agree with you. What confuses me, though, is the fact that the
> ASF doesn't control and enforce its policies in every project.
> Communication is the key. as always....
> 

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


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

Re: Fop and JDK1.2

[Peter B. West]

Christian,

Just did it.

New <http://xml.apache.org/fop/news.html>
  updated <http://xml.apache.org/fop/status.html>
  updated <http://xml.apache.org/fop/design/alt.design/index.html>

Peter

Christian Geisert wrote:
> Peter B. West schrieb:
> 
>> plans to use the News page on the web-site to maintain a short history 
>> of releases and release candidates.  The sort of notes that appear in 
> 
> Just do it ;-)
> 
>> the release announcements could be collected there and serve as an 
>> immediate point of reference.


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


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

Using bugzilla

[Peter B. West]

Foplings,

I'm only just beginning to realise how useful bugzilla is, in spite of 
having watched numerous mozilla bugs over a long period.  I can see it 
complementing the dev list very nicely, both for bug fixing and some 
redesign work.  The beauty of it is that it provides a focus for 
discussions on particular issues, and lets the relationships and 
dependencies between issues be directly specified.

A simple example of its usefulness would be the changes to the Xalan1 
dependencies in the build.  The procedure would be to initiate 
discussion on fop-dev, and it the feeling is to go ahead, raise a RFE in 
bugzilla.  Then whenever anything is done in connection with the change, 
note it in bugzilla.  All of the bugzilla FOP activity echos in fop-dev, 
so everyone can see what is happening, and join in on bugzilla with any 
direct comments.  That way all of the discussion about a particular 
topic can be found in the one place, without having to trawl through the 
mail archives to follow the argument.

(Anyone who is lurking on fop-dev and wants to make a comment could do 
it on the list anyway.  If he wants to get more involved, a bugzilla 
login is a minute away.)

??

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


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

Re: Fop and JDK1.2

[Peter B. West]

Christian (and Satoshi),

Thanks for clarifying this.  If nothing has changed in this respect from 
0.20.3, then nothing is going to break for any users who upgrade from 
0.20.3 to 0.20.4 (at least in this respect.)  No drama.

The discussion has thrown up some interesting points, and I hope to see 
Rhett get involved in this soon.

I hope also that the work Rhett is talking about will give us a solid 
framework for changes to our support framework, both with the JVM and 
possibly with the frequently changing jars that we bundle.  There may be 
other initiatives happening within Apache on that front.

I noticed again, following Satoshi's email, that we have no tags for 
RCs.  I think this is an oversight which should be addressed.  Are there 
plans to use the News page on the web-site to maintain a short history 
of releases and release candidates.  The sort of notes that appear in 
the release announcements could be collected there and serve as an 
immediate point of reference.

Peter

Christian Geisert wrote:
> Peter B. West schrieb:
> 
> Ok, I'll try to explain.
> 
> The standard fonts (times, courier etc.) are mapped fix to Java fonts
> (Serif, MonoSpaced etc. - which are actually truetype fonts I think).
> Additonal (truetype) fonts are loaded with a method in java.awt.Font
> which was first introduced in jdk1.3 (The font is loaded with the full
> path and not created with the name).
> While running under jdk1.2 the NoSuchMethodException is caught and one
> of the standard fonts will be used instead.
> This way it was already done in 0.20.3.
> 
> Hope this clarifys the issue a bit.
> 

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


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

Re: Fop and JDK1.2

[Peter B. West]

Can anyone answer the questions below?  Hopefully, before the release.

I think we need to discuss these issues in more depth.  We have people 
using FOP in production, and, in spite of the fact that everyone is 
aware that FOP is pre-beta, and that everything about it is subject to 
change, we should show some concern for issues which impact production 
environments.  There is not an immediate necessity to publish 0.20.4; it 
can be delayed a little while we try to find out more about these issues.

Further to one of my points below: if TT fonts are not supported in AWT 
in 0.20.3, then the proposed interim solution of compiling with 1.3 and 
notifying users that TT fonts will not work with 1.2 looks OK.

Peter

 Original Message 

I'm confused about exactly what the nature of the problem is here.  From
what I can gather so far, not insisting on 1.3 means that we must
withdraw support for TT fonts in AWT.  Does that imply that TT fonts
were not supported in AWT in 0.20.3?  If so, not supporting them in
0.20.4 is not a backward step, it is the maintenance of the status quo.
   If some users have got used to AWT TT support in CVS versions of FOP,
we can, with a little footwork, do both: we can provide a 0.20.4 release
which can still be built with 1.2, without TT, for users of 0.20.3.  For
those users who are in the habit of building from the CVS tree, we can
immediately restore the AWT TT support in the tree, while we work on a
proper version-dependetn regime for the following release.

If AWT TT support was provided by some other means in 0.20.3, why don't
we stick with that for now?

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


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

Re: Fop and JDK1.2

[Peter B. West]

Rhett,

I was originally thinking along the lines you have suggested.  In fact, 
I have been vaguley thinking along these lines for some time, triggered 
by the build contortions we have seen in the past.  My preference is to 
sort out as much as possible (and feasible) at run-time.  However, 
because I have no experience in the complexities of class loaders, etc, 
I was loathe to suggest it.

I'm with you in trying to alleviate as much of the burden as possible 
for users.  At the end of the day, the product that is the easiest to 
set up and use has a huge advantage.  Ask Microsoft.

Peter

Rhett Aultman wrote:
> Peter,
> 
> Rather than building multiple version dependant JARs
  and having users select the best one, perhaps we could,
  behind an interface that effectively hides the issue,
  detect the version of the VM being run and dynamically
  load appropriate handler classes?  This alleviates the
  burden of users selecting appropriate JARs.
> 
> As you said, it does increase complexity, and the only
  case we're dealing with thus far can be solved in other
  ways, but I suspect that this is a problem that's only
  going to grow over time as we find other JVM version
  (and *VENDOR*) inconsistancies.


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


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

Re: Fop and JDK1.2

[Peter B. West]

I'm confused about exactly what the nature of the problem is here.  From 
what I can gather so far, not insisting on 1.3 means that we must 
withdraw support for TT fonts in AWT.  Does that imply that TT fonts 
were not supported in AWT in 0.20.3?  If so, not supporting them in 
0.20.4 is not a backward step, it is the maintenance of the status quo. 
  If some users have got used to AWT TT support in CVS versions of FOP, 
we can, with a little footwork, do both: we can provide a 0.20.4 release 
which can still be built with 1.2, without TT, for users of 0.20.3.  For 
those users who are in the habit of building from the CVS tree, we can 
immediately restore the AWT TT support in the tree, while we work on a 
proper version-dependetn regime for the following release.

If AWT TT support was provided by some other means in 0.20.3, why don't 
we stick with that for now?

Peter


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


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

Re: Fop and JDK1.2

[Peter B. West]

Christian et al,

My comparative ignorance of Java hampers me here, but might it not be 
possible to provide some sort of upgrade insurance by attempting to 
isolate version-dependent components behind access classes which provide 
a common interface and graceful degradation in the case of unsupported 
features?  Put all of the version-dependent classes in a separate jar, 
and compile and build that jar with the current version.  Notify users 
about this problem, and get those with particular environments to build 
fop-jverdep.jar (or whatever) and feed it back to us.  The binary 
download environment can be set up to accommodate each supported Java 
version, with the fop.jar as a common link.

Obviously it's more work for us, and more discipline when introducing 
new features, but it takes care of the customers.  That's if it can be 
done at all.

Peter

Christian Geisert wrote:
> Hi,
> 
> Building Fop with JDK1.2 does not work at the moment.
> 
> The problem is the method java.awt.Font.createFont(..) which
> is used by the AWT viewer for displaying truetype fonts and
> is avaible first since JDK1.3.
> 
> So what should we do?
> 
> 1) Declare that Fop needs JDK1.3
> 
> 2) Remove truetype font support from AWT viewer
> 
> 3) Compile Fop with JDK1.3 (which will be done anyway)
> and state in the release notes that compiling with JDK1.2
> and using truetype fonts in the AWT viewer does not work.
> 

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


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

Re: delay for release candidate

[Peter B. West]

Rob,

Thanks.  That's exactly the sort of thing I was concerned about.  I've 
had a quick look around and seen nothing, so it might be better for now 
to put it on hold, and mention the work-around and its possible 
consequences in the release notes.  Anyone else have any other ideas?

Peter

Rob Smith wrote:

>>What's the latest?  I have just patched .../fo/flow/BasicLink.java to
>>change the default, but I have not committed it yet.  I would like to
>>get an interested user to try it before general release, if possible.
> 
> 
> There is a rather odd bug that showed up when I set -Dlinks.merge=yes on the
> command line. The following FO:
> 
> 
>   
> 1.
> Introduction
>   
>   
>   
>   
>   
>   
>   
> 
> 
> caused FOP to report:
> [ERROR]: 0 >= 0
> 
> The FO comes from a Docbook stylesheet, and is part of the table of contents
> (actually most Docbook+FOP users won't get this error because Docbook
> produces a different TOC format without leaders if the "fop.extensions"
> parameter is set to "1").
> 
> The problem seems to be due to the sequence (basic-link leader basic-link)
> in a justified block. Removing any one of these fixes it, as does making the
> whole line a single basic-link.
> 
> Trouble is, changing the links.merge default could break some documents with
> a very obscure error message.

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


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

Re: delay for release candidate

[Peter B. West]

Christian,

What's the latest?  I have just patched .../fo/flow/BasicLink.java to 
change the default, but I have not committed it yet.  I would like to 
get an interested user to try it before general release, if possible.

Peter

Christian Geisert wrote:
> Hi all,
> 
> as you probably have noticed the date for the release candidate has been
> reached but I would like to see the following things done for 0.20.4:
> (new target date: next weekend ;-)
> 
> - fix multiple rectangle links
>   http://marc.theaimsgroup.com/?l=fop-dev&m=102212484928910&w=2
>   http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9335

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


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

Re: header image of http://xml.apache.org/fop/index.html

[Peter B. West]

Oleg,

Known problem, which has actually been solved, as you can see if you 
build htmldoc in a CVS HEAD checkout.  Some of the graphics haven't made 
their way into the website tree yet.  I'll have a look at it.

Peter

Oleg Tkachenko wrote:
> Hello there!
> 
> I just noticed that header image at fop's index page looks rather 
> bizarre - there is probably white "FOP" string at the right, but what I 
> can see (mozilla1.0 or IE6) is only left bottom corner of letters "FO". 
> Can anybody else see it?
> 


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


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

Re: Info on my efforts for the 0.20.4 release

[Peter B. West]

Jeremias,

I'm pleased to hear this.  I believe that the PS renderer is an 
important part of FOP's future.

Peter

Jeremias Maerki wrote:
> Hi Chrisian and other foppers
> 
> Yesterday, I started to work on incorporating Huikang Xu's patch for the
> PS renderer. As things go, I've found a pile of things in the PS
> renderer I didn't like, so I started to hack around. The good message
> is: The PS renderer will get a few improvements (all bug fixes by
> Huikang Xu, better DSC compliance, correct image placement, totally
> refactored encoding filters that don't throw occasional Exceptions
> anymore etc.). The bad message is: It got late last night and I haven't
> finished and I won't be able to finish today. So, Christian, if you
> manage to get the release candidate out today, go for it. I'll commit my
> changes after the final release. Sorry.
> 

P.S. Re: the sudden re-appearance of my .sig.  Don't be alarmed.  I have 
just done a clean install of Mozilla 1.0, and rebuilt my prefs.js file 
in the process.  This simple action has cleared a couple of 
long-standing movemail bugs for me, including the loss of a .signature 
file.  Isn't the 1.0 release a mighty achievement?
-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


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

Re: Exploring the FOP API design space

[Peter B. West]

Keiron,

You have nicely summarised the references to the user agent in the spec 
(except for the first one, invalid markup error handling, which I think 
you have added.)  However, my problem with the notion in the spec of 
user agent remains.  The authors have never bothered to define it, and 
we are left to work out what, exactly, it is from the various 
references.  The references that we have - certainly the references to 
non-interactive agents - are all to configuration items.  At the moment 
these things are, as I said, in the XML files.  It would, prima facie, 
be straightforward to get this from the configuration, in whatever form 
that eventually takes, whether we continue to use the XSLT, or introduce 
the properties into the CVS tree.  I.e., whatever form the expression of 
the properties takes, we would need to extract certain key property 
values from the configuration.

Assuming that we have no plans to go into the interactive presentation 
business as yet, we can disregard the interactive elements.  Even where 
an interactive agent would presumably expose the options for 
modification, those elements would still require initial values.  For 
our purposes, I think that "user agent" functions should be merged into 
configuration.

Incidentally, I think the multi-properties, title and hot links elements 
should be in the "Interactive" list.  The aural properties 
(pause-before, pause-after, voice-family) are not necessarly 
interactive.  It would be quite feasible to produce an audio file 
rendering of a document within FOP.

Peter

Keiron Liddle wrote:

>maybe this could answer your question:
>http://xml.apache.org/fop/design/useragent.html
>
>ie. FOP is the user agent but in some cases people might want to alter
>certain behaviour. So we provide a class to enable this.
>
>On Tue, 2002-06-04 at 19:29, Peter B. West wrote:
>  
>
>>As a result of this exercise, I remain as confused as ever. The most 
>>general sense of "user agent" seems to be "fo processor". There are 
>>"interactive user agents" which may have "user agent windows". User 
>>agents determine actual values for a number of enumerated values, and 
>>determine a number of critical default values. Things which are 
>>currently defined in Properties XML files, and transferred from there 
>>into the source code, are therefore user agent functions.
>>
>>



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

Re: Support for float

[Peter B. West]

Jason Foster wrote:

> I'm just curious, as I see messages talking about re-architecting, 
> what the plans are for supporting the  element? I've searched 
> the archives and couldn't find any substantive discussions on the matter.
>

Jason,

In spite of the lack of substantive discussion, fo:float will definitely 
be supported in the redesign.

Peter



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

Re: Exploring the FOP API design space

[Peter B. West]

Hello all.

There was some talk about user agents, which sent me back to the spec. I 
have never had any solid sense of what the user agent was all about, so 
I have collected all of the references to "user agent" from the spec. 
They should soon be available on the web site under NEW DESIGN->ALT 
DESIGN->User agent refs, and the xml is in the HEAD. The html can be 
generated from a `cvs update'd trunk by
$ ./build.sh html-altdesign

As a result of this exercise, I remain as confused as ever. The most 
general sense of "user agent" seems to be "fo processor". There are 
"interactive user agents" which may have "user agent windows". User 
agents determine actual values for a number of enumerated values, and 
determine a number of critical default values. Things which are 
currently defined in Properties XML files, and transferred from there 
into the source code, are therefore user agent functions.

Peter



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

Re: [REDESIGN] configuration

[Peter B. West]

Keiron,

I can't comment on the details of this unless and until I look at 
avalon.  I notice, though, that version is still given as a 
configuration parameter.  Does that mean that a user can arbitrarily 
change the FOP version?  My point, of course, is that version has 
nothing to do with configuration.

Peter

Keiron Liddle wrote:

>Hi,
>
>Here are some ideas about how we could do the configuration for FOP.
>Comments are welcome.
>
>Use this class and various supporting classs (already in avalon
>framework jar):
>org.apache.avalon.framework.configuration.Configuration
>  
>



>
>
>
>
>
>  
>




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

Re: Structure Handlers - RTF Renderer

[Peter B. West]

  Bertrand,

<
I started writing this before the flurry of messages in the last day or 
two, so it may now be redundant.  If so, however, I have missed part of 
the conversation.  My recollection of consensus of opinion some months 
ago was as I state just below.
 >

I think you will still have attribute resolution problems.  Remember 
that some attributes are only going to be resolved during the layout.

It seems to me that the general solution would involve the definition of 
a structure api, taking account of the layout dependencies.  to get 
there, you need to define an XML equivalent of the structure that is 
presented to the RTF renderer.  Define all of the data types that are 
being passed into RTF, and isolate the circumstances in which 
information cannot be passed across prior to layout.  Out of that you 
might get three interface definitions: ideal RTF, layout RTF and FOTree 
RTF.  With any luck, ideal RTF would co-incide completely with layout 
RTF, and differ only in a few minor details from FOTree RTF.

Then have the same thing done for, say, MIF.  From a comparison of the 
layout MIF and FOTree MIF, try to develop a general FOStructure API 
which will hopefully be flexible enough to accommodate any other 
structure renderers which come along.  The danger in not doing that is 
that you end up with an FOStructure API that is only an RTFStructure API.

It may be necessary to build in a fundamental option to choose, e.g., 
layout RTF or FOTree RTF.  In the latter case, the User Agent would 
arbitrate unresolved arrtibutes; in the former, the layout engine would 
have to proceed far enough to resolve all of the attributes.  One 
possibility in the former case is that you _may_ find it is possible to 
do the transformation to FOTree RTF in XSLT.  Just a flight of fancy 
perhaps.

You may already have documented the structure transformations needed for 
FO->RTF.  If so, it would be a very good idea to include them in the NEW 
DESIGN documentation.

Peter


Bertrand Delacretaz wrote:

>Hi Keiron,
>
>  
>
>>. . .
>>This structure handler will have a number of methods for the start and
>>end of elements like block, table, list item etc. and others for
>>external graphic etc. 
>>. . .
>>
>>
>
>I agree that high-level events like start/end block, table, etc. are what we 
>need for structure rendering. 
>
>Currently jfor works by mapping SAX events (that come directly from parsing 
>the XSL-FO) to the construction of RTF objects, so the kind of interface that 
>you mention would certainly help integrating the current jfor code.
>
>  
>
>>It will pass appropriate information, mostly the
>>current fo object.
>>
>>
>
>Maybe passing a compound object (StructureRendererContext?) that *contains* 
>the current fo object would help, as the renderer might need to access 
>configuration, logging or other services.
>
>  
>
>>. . .
>>Currently the StreamRenderer does a very limited version with start, end
>>document and end page sequence. This could become a subclass of the
>>structure handler where it will only use a few methods (probably should
>>rename it to RenderHandler).
>>. . .
>>
>>
>
>Looks good to me - basing the current rendering process on the structure 
>rendering stuff certainly makes sense.
>
>If I get it right, the processing pipeline would then look as follows:
>parsing -> SAX events -> validation -> attribute resolution -> structure 
>rendering (SR)
>
>Where SR is either "RTF rendering" or "layout -> PDF rendering"
>
>- Bertrand
>  
>



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

Re: build changes

[Peter B. West]

J.Pietschmann wrote:

> If you really like a challenge, talk the other apache
> projects into using a standardised top-level directory
> structure with one doc, one src and so on :-)


pietsch,

Do I want more of a challenge than FOP? You must be joking. Ahh, I see 
that you are.

Peter



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

Re: build changes

[Peter B. West]

Foppers,

I'm beginning to realise what a mighty cultural gulf I'm talking across. 
As an aid to understanding, I have just tried the following on my linux 
system. (Note that we are talking binaries here.)

$ cd /usr/bin
$ ls | (xargs ident 2>/dev/null) | less

The results are patchy. For most files you see a results like

<
artsmessage:

artsplay:

artsrec:

 >
i.e. No keywords. Then you get things like

<
cancel:
$Id: lprm.c,v 1.19 2002/03/06 17:02:54 papowell Exp $

 >
and at the other end of the scale

<
mailq:
$Id: main.c,v 8.485.4.65 2001/07/20 00:53:00 gshapiro Exp $
$Id: sendmail.h,v 8.517.4.70 2001/08/14 23:08:12 ca Exp $
$Id: alias.c,v 8.142.4.11 2001/05/03 17:24:01 gshapiro Exp $
$Id: arpadate.c,v 8.23.20.2 2001/05/07 22:07:26 gshapiro Exp $
$Id: bf_portable.c,v 8.25.4.6 2001/05/03 17:24:01 gshapiro Exp $
$Id: clock.c,v 8.52.18.18 2001/08/14 16:07:04 ca Exp $
$Id: collect.c,v 8.136.4.22 2001/06/07 21:01:02 ca Exp $
$Id: conf.c,v 8.646.2.2.2.87 2001/07/20 23:56:52 gshapiro Exp $
$OrigId: getloadavg.c,v 1.16 1991/06/21 12:51:15 paul Exp $
$Id: control.c,v 8.44.14.20 2001/05/03 17:24:03 gshapiro Exp $
$Id: convtime.c,v 8.25 1999/06/16 21:11:26 ca Exp $
$Id: daemon.c,v 8.401.4.68 2001/07/20 18:45:58 gshapiro Exp $
$Id: deliver.c,v 8.600.2.1.2.86 2001/07/20 21:52:55 gshapiro Exp $
$Id: domain.c,v 8.114.6.1.2.8 2001/02/12 21:40:19 gshapiro Exp $
$Id: envelope.c,v 8.180.14.10 2001/05/03 17:24:06 gshapiro Exp $
$Id: err.c,v 8.120.4.5 2001/08/17 22:09:40 ca Exp $
$Id: headers.c,v 8.203.4.13 2001/05/03 17:24:06 gshapiro Exp $
$Id: macro.c,v 8.40.16.9 2001/02/22 01:16:55 gshapiro Exp $
$Id: map.c,v 8.414.4.55 2001/08/15 22:08:58 gshapiro Exp $
$Id: mci.c,v 8.133.10.8 2001/05/03 17:24:10 gshapiro Exp $
$Id: milter.c,v 8.50.4.53 2001/08/15 02:01:03 ca Exp $
$Id: mime.c,v 8.94.16.3 2000/10/09 02:46:10 gshapiro Exp $
$Id: parseaddr.c,v 8.234.4.13 2001/08/14 23:08:13 ca Exp $
$Id: queue.c,v 8.343.4.62 2001/07/20 00:53:01 gshapiro Exp $
$Id: readcf.c,v 8.382.4.43 2001/08/14 23:08:13 ca Exp $
$Id: recipient.c,v 8.231.14.11 2001/05/03 17:24:14 gshapiro Exp $
$Id: savemail.c,v 8.212.4.13 2001/05/03 17:24:15 gshapiro Exp $
$Id: sfsasl.c,v 8.17.4.15 2001/07/11 17:37:07 gshapiro Exp $
$Id: shmticklib.c,v 8.6 2000/02/26 01:32:27 gshapiro Exp $
$Id: srvrsmtp.c,v 8.471.2.2.2.78 2001/06/26 18:52:21 gshapiro Exp $
$Id: stab.c,v 8.40.16.7 2001/05/07 22:06:41 gshapiro Exp $
$Id: stats.c,v 8.36.14.5 2001/02/14 04:07:30 gshapiro Exp $
$Id: sysexits.c,v 8.25 1999/09/23 19:59:24 ca Exp $
$Id: timers.c,v 8.13.16.1 2000/10/09 01:06:45 gshapiro Exp $
$Id: trace.c,v 8.20.22.4 2001/08/15 13:05:43 ca Exp $
$Id: udb.c,v 8.111.16.2 2001/05/03 17:24:17 gshapiro Exp $
$Id: usersmtp.c,v 8.245.4.34 2001/06/26 21:55:23 gshapiro Exp $
$Id: util.c,v 8.225.2.1.2.26 2001/06/01 08:23:25 gshapiro Exp $
$Id: version.c,v 8.43.4.39 2001/08/20 14:45:34 gshapiro Exp $
$Id: debug.c,v 8.2 1999/07/26 04:04:09 gshapiro Exp $
$Id: safefile.c,v 8.81.4.10 2001/07/20 04:19:36 gshapiro Exp $
$Id: snprintf.c,v 8.27.16.4 2001/07/20 04:19:37 gshapiro Exp $
$Id: strl.c,v 8.5.14.2 2000/09/17 17:04:24 gshapiro Exp $

 >

rcs, as one might expect, looks like
<
rcs:
$Id: rcsbase.h,v 5.20 1995/06/16 06:19:24 eggert Exp $
$Id: rcs.c,v 5.21 1995/06/16 06:19:24 eggert Exp $
$Id: rcslex.c,v 5.19 1995/06/16 06:19:24 eggert Exp $
$Id: rcssyn.c,v 5.15 1995/06/16 06:19:24 eggert Exp $
$Id: rcsrev.c,v 5.10 1995/06/16 06:19:24 eggert Exp $
$Id: rcsutil.c,v 5.20 1995/06/16 06:19:24 eggert Exp $
$Id: rcsgen.c,v 5.16 1995/06/16 06:19:24 eggert Exp $
$Id: rcsedit.c,v 5.19 1995/06/16 06:19:24 eggert Exp $
$Id: rcskeys.c,v 5.4 1995/06/16 06:19:24 eggert Exp $
$Id: rcsmap.c,v 5.3 1995/06/16 06:19:24 eggert Exp $
$Id: rcsfnms.c,v 5.16 1995/06/16 06:19:24 eggert Exp $
$Id: rcskeep.c,v 5.10 1995/06/16 06:19:24 eggert Exp $
$Id: maketime.c,v 5.11 1995/06/16 06:19:24 eggert Exp $
$Id: partime.c,v 5.13 1995/06/16 06:19:24 eggert Exp $
$Id: rcstime.c,v 1.4 1995/06/16 06:19:24 eggert Exp $

 >

On the other hand, there's
<
$ ident /usr/sbin/httpd
/usr/sbin/httpd:
ident warning: no id keywords in /usr/sbin/httpd
 >

Peter


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

Re: build changes

[Peter B. West]

Arved Sandstrom wrote:

>>-Original Message-
>>From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
>>
>>
>>
>Ant is a cross-platform (by virtue of Java and XML) makefile system,
>basically, optimized for Java projects. Which is not new information.
>Sometimes we all lose sight of the fact that that is all it is. I have yet
>to do anything with Ant that I couldn't have done with a standard makefile;
>it just happens that Ant is easier to use for complex Java projects.
>
>Ant imposes no standards for versioning or configuration management. That
>would be well outside the scope of the tool. What it does provide are useful
>tasks for simplifying whatever versioning and CM a team decides to employ.
>Apart from open-source use of Ant (mainly with FOP) I have used Ant in
>real-life for over 2 years. At one company the versioning and CM was based
>on IEEE, so we tailored our buildfiles to do that. There we used CVS. At my
>current place of employ, Hummingbird, we use Ant with VSS and our own
>versioning standards - our buildfiles are tailored to support _that_. And
>Apache projects are different yet again.
>
>I don't find it unusual or objectionable that the version information is not
>automated. If we did regular builds that would be a candidate for
>automation, certainly, but we don't (Gump does, admittedly, but _we_ don't).
>Finally, I think it would be reasonable to automate labelling (tagging) in
>conjunction with an actual release. But overall I don't think things are
>that bad.
>  
>

The automation of release labelling is not the main issue, just the 
easiest to fix.  If release labelling were all there was to it, it would 
be neither here nor there.  The main game is binary accounting; the 
assurance that a release is what it says it is, down to the very last 
file.  That's a big ask, where you have image files, e.g.   It is not a 
big issue for text-based files though.

What approach is taken in the places you mention to the identification 
of binary components?

Peter


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

Re: Keiron Liddle Elected To ASF

[Peter B. West]

Arved Sandstrom wrote:

>Hi, all
>
>I am very pleased to announce that Keiron has been elected to membership in
>the Apache Software Foundation, effective tomorrow (voting finished today).
>I'd like to be the first to extend my hearty congratulations. :-)
>  
>
Keiron,

Let me be the third.  Hearty congratulations.  This is a considerable 
achievement.

Peter



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

Re: build changes

[Peter B. West]

Keiron,

See below.

Keiron Liddle wrote:

>Hi Peter,
>
>On Thu, 2002-05-23 at 12:51, Peter B. West wrote:
>  
>
>>The full range of what I want to do with versioning I am not sure of; 
>>the minimum I am sure of.  I canvassed this a short time ago.  That is, 
>>to eliminate the situation where the identification of a build depends 
>>on manual intervention in the build.xml file which may or may not match 
>>a tag in the CVS tree, which may or may not correspond to the full set 
>>of files in the release.  I am astonished that this situation is 
>>tolerated, although I should not be astonished to be told that it is the 
>>general condition of Ant-based builds.
>>
>>
>
>Considering that *every* project has a version you would think there is
>a standard and robust way of handling this.
>

My question mark is over the "robust".

>>The first thing is to get the version information returned by the 
>>Version class to match a tag.  That's easy.  Include $Name$ and $Header$ 
>>in Version.java as, say, private static final String fields, and include 
>>getTag() and getHeader() methods which simply return those values. 
>> Modify getVersion() to manipulate the $Name$ tag value, expressed 
>>according to the convention which I have also canvassed, without 
>>response, here earlier.  If there is no $Name$ value, a default version 
>>string, something like "FOP.Development" (a string which could not be 
>>generated from a legitimate tag) would be returned.
>>
>>
>
>One situation that might need considering is when there is no cvs. For
>example the source distribution. They may also want to set the version
>number themselves.
>  
>

Of course.  All bets are off when the version control situation changes. 
 But that possibility should not inhibit us, who are working from the CVS.

>>That, obviously, is fairly easy to do.  Trickier problems include:
>>
>>Reporting the new getVersion() string during the build.  Done fairly 
>>easily by an Ant task which simply emits the derived string to the 
>>normal verbiosity stream.  Should probably involve similar labelling 
>>procedures in Version.java and build.xml.
>>
>>Validating that the whole source tree corresponds to the tag in 
>>Version.java.  This necessarily involves the inclusion of keywords in 
>>every source file of the build.  Now there's a novel idea.  Another task 
>>required, and it would be useful if I could get the canonical tag value 
>>back into the build somehow, as for example with backquotes in a 
>>shell-based unix build process.  I don't know how to do this in Ant.
>>
>>I want to look at all of these things, but clearly not all before 0.20.4.
>>
>>Let me say a few words about the CVS tree.  It's not a sacred site.  It 
>>has branches in order, among other things, to enable isolated 
>>development.  IMHO, all individual development should take place on 
>>personal branches, unless multiple developers are closely co-ordinating 
>>attacks on particular pieces of code.  Make changes, find out what 
>>others are up to, merge into your own branch from the trunk as 
>>necessary, and when you're ready, notify everyone that you want to merge 
>>back to the trunk.  Do that.  Find, and resolve with the other 
>>developers any merge conflicts.  Abandon the branch.  Throw another one 
>>and move on.  This tool allows such things to happen and protects 
>>everybody's investment, so let's take advantage of it.  If a branch is 
>>abandoned without ever being integrated into a release, so what?
>>
>>
>
>That is true.
>On the other hand this sort of approach does not enforce and promote
>community development.
>

I think that "enforcing" and "promoting" community development are 
inimical concepts.  I agree entirely that it does not enforce community 
development.  Whether it promotes community development depends on your 
definition of that concept.  At the least, I would not accept that it 
militates *against* community development.

> In practice branches are used for version and
>maintenance+bugfix or major changes and development occurs in the one
>place. For unproved concepts something like a scratchpad is used.
>

I accept that that is the current practice.  However, AFAICT, there is 
no compelling reason not to vary this practice.

> Also
>this doesn't really scale with more developers.
>

I see your point here.  As more developers are added, and as more 
merge/resolve cycles occur, the overheads of the merge/resolve cycle 
become much greater and more time-consuming.  However, the single-branc

Re: Running Prefligh PDF tools on PDF files produced by FOP

[Peter B. West]

Matt, Matthew,

Maybe you could try generating the most minimal possible PDF file which 
still crashes the preflight programs.  Use the same fo: source file in 
XEP and Antenna and compare the output.  Send these PDF files to Enfocus 
ior Adobe for comment.  If someone there can tell us exactly what 
constructs are causing the problem, we will have a target.

Peter

Matt Johnston wrote:

>I have run into the exact same problem.  I have personally tried Pitstop and
>had the same error occur.  Other people that have several industrial
>strength preflight tools said that the PDFs I made out of FOP crashed all
>their programs.  The only preflight program I can get to read the PDF is
>Flightcheck.  Plus, certain versions of Photoshop(5.0) and Illustrator(8,9)
>also do not like the file format, while Acrobat Reader reads them fine.
>This is a problem that I too would like to see solved.
>
>-Original Message-
>From: Matthew Brook O'Donnell [mailto:[EMAIL PROTECTED]]
>
>  
>



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

Re: Latest version (f) of FO Schema

[Peter B. West]

Oleg Tkachenko wrote:

> Peter B. West wrote:
>
>> I suppose a lot depends on how tightly you want to try to constrain 
>> the XSL through the schema.  There are many constraints which can 
>> only be tested by the processor.
>
>
> Do you mean constraints which are just impossible to express due to 
> schema restrictions (cooccurence etc) or constraints which couldn't be 
> tested on xsl-fo as xml document stage at all?
>
Oleg,

I should have said, "which are highly context dependent and would be 
cumbersome to express outside the processor."  I simply don't know how 
expressive XML Schema is.  I had in mind, for example, the kinds of 
constraints involved with the use of certain functions.  On a slightly 
different tack, I was also uncertain of the target audience for the 
schema.  The vast majority of instances of fo: elements and associated 
attributes will occur in stylesheets such that the final shape of the 
fo: elements cannot be determined except by running the transformation.

Peter


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

Re: build changes

[Peter B. West]

Keiron Liddle wrote:

>On Wed, 2002-05-22 at 17:30, Peter B. West wrote:
>  
>
>>Are you *trying* to annoy me, or does it just happen?  I don't want to 
>>jump to conclusions.
>>
>>
>
>Relax, I'm not trying to annoy you.
>  
>

Keiron,

Thanks for that, and my apologies for the sharp tone.  I have to confess 
that I was in a very short mood; the Maroons had just been thrashed. 
 That's no excuse, of course.  See my earlier response.

Peter



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

Re: build changes

[Peter B. West]

Keiron Liddle wrote:

>On Tue, 2002-05-21 at 05:46, Peter B. West wrote:
>  
>
>>Ladies and gentlemen, boys and girls,
>>
>>What's the state of play now with the changes to the build system?  Has 
>>the elimination of Xalan1 been completed?  Who's doing what there?
>>
>>I am planning to throw a branch off HEAD to tinker with at least the 
>>versioning information for the build.
>>
>>
>
>What exactly do you want to do with the versioning etc.
>Can you give us a rundown of what it will do and how?
>
>btw If you want to "tinker" with cvs you can do it all on your own
>machine.
>  
>

Keiron,

The full range of what I want to do with versioning I am not sure of; 
the minimum I am sure of.  I canvassed this a short time ago.  That is, 
to eliminate the situation where the identification of a build depends 
on manual intervention in the build.xml file which may or may not match 
a tag in the CVS tree, which may or may not correspond to the full set 
of files in the release.  I am astonished that this situation is 
tolerated, although I should not be astonished to be told that it is the 
general condition of Ant-based builds.

The first thing is to get the version information returned by the 
Version class to match a tag.  That's easy.  Include $Name$ and $Header$ 
in Version.java as, say, private static final String fields, and include 
getTag() and getHeader() methods which simply return those values. 
 Modify getVersion() to manipulate the $Name$ tag value, expressed 
according to the convention which I have also canvassed, without 
response, here earlier.  If there is no $Name$ value, a default version 
string, something like "FOP.Development" (a string which could not be 
generated from a legitimate tag) would be returned.

That, obviously, is fairly easy to do.  Trickier problems include:

Reporting the new getVersion() string during the build.  Done fairly 
easily by an Ant task which simply emits the derived string to the 
normal verbiosity stream.  Should probably involve similar labelling 
procedures in Version.java and build.xml.

Validating that the whole source tree corresponds to the tag in 
Version.java.  This necessarily involves the inclusion of keywords in 
every source file of the build.  Now there's a novel idea.  Another task 
required, and it would be useful if I could get the canonical tag value 
back into the build somehow, as for example with backquotes in a 
shell-based unix build process.  I don't know how to do this in Ant.

I want to look at all of these things, but clearly not all before 0.20.4.

Let me say a few words about the CVS tree.  It's not a sacred site.  It 
has branches in order, among other things, to enable isolated 
development.  IMHO, all individual development should take place on 
personal branches, unless multiple developers are closely co-ordinating 
attacks on particular pieces of code.  Make changes, find out what 
others are up to, merge into your own branch from the trunk as 
necessary, and when you're ready, notify everyone that you want to merge 
back to the trunk.  Do that.  Find, and resolve with the other 
developers any merge conflicts.  Abandon the branch.  Throw another one 
and move on.  This tool allows such things to happen and protects 
everybody's investment, so let's take advantage of it.  If a branch is 
abandoned without ever being integrated into a release, so what?

Peter


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

Re: Latest version (f) of FO Schema

[Peter B. West]

Chuck,

See below.

Chuck Paussa wrote:

> I haven't coded for the possibility of including functions in 
> attribute values.
> Which functions has FOP implemented?


The functions are designed for use in attribute values, so sooner or 
later



> Also, Can I assume that the following is true?
>
>   1. All functions that return object can be applied anywhere.

The most general of the object-returning functions are from-parent() and 
from-nearest-specified-value().  They are only errors in some tightly 
restricted circumstances.

system-font() is also pretty general; it can return a , e.g., 
but with a catch.  There are two forms: system-font(fontname) and 
system-font(fontname, font-property).  In the second, the only 
restriction on the target is the obscure relationship between the 
computed type of the font-property and the allowable types of the target 
property.  If the font-property is font-size, a  is returned 
which can be applied to any attribute taking a .  But in the 
second form, it can only be applied to a font-property attribute, e.g. 
font-size.  Nasty.

inherited-property-value() is general, except that it is an error of the 
property in question is not inheritable.

from-table-column - see your point 4.

merge-property-values() must occur in a child of fo:multi-properties.

>   2. Numeric functions apply to length, integer, and number values.


So far.  But there is a hole in the spec involving ,  and 
, which you should keep in mind.  There must be something 
about these in the next release.  Fortunately for FOP, they do not 
relate printed output.

>   3. Color functions apply to color values.
>   4. from-table-column applies to table-cell and any element that can
>  be a child of a table-cell.
>   5. proportional-column-width applies only to table-column
>
> Functions:
> numericfloor( numeric)
> numericceiling(numeric)
> numericround(numeric)
> numericmin( numeric , numeric)
> numericmax(numeric , numeric)
> numericabs( numeric)
> colorrgb(numeric , numeric , numeric)
> colorrgb-icc(numeric , numeric , numeric , NCName , numeric , 
> numeric)
> colorsystem-color( NCName)
> objectsystem-font( NCName , NCName)
> objectinherited-property-value(NCName)
> numericlabel-end()
> numericbody-start()
> objectfrom-parent( NCName)
> objectfrom-nearest-specified-value( NCName)
> objectfrom-table-column( NCName)
> numericproportional-column-width( numeric)
> objectmerge-property-values( NCName)
>
> The spec also specifies this attribute, which applies to the page 
> context (So which elements signify the page context?)
> 

Size in XSL is regarded as a shorthand for page-height and page-width. 
 These properties are only defined on fo:simple-page-master.

I suppose a lot depends on how tightly you want to try to constrain the 
XSL through the schema.  There are many constraints which can only be 
tested by the processor.

Peter


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

Re: build changes

[Peter B. West]

Keiron Liddle wrote:

>On Tue, 2002-05-21 at 05:46, Peter B. West wrote:
>  
>
>>Ladies and gentlemen, boys and girls,
>>
>>What's the state of play now with the changes to the build system?  Has 
>>the elimination of Xalan1 been completed?  Who's doing what there?
>>
>>I am planning to throw a branch off HEAD to tinker with at least the 
>>versioning information for the build.
>>
>>
>
>What exactly do you want to do with the versioning etc.
>Can you give us a rundown of what it will do and how?
>
>btw If you want to "tinker" with cvs you can do it all on your own
>machine.
>
>  
>
Keiron,

Are you *trying* to annoy me, or does it just happen?  I don't want to 
jump to conclusions.

Peter


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

Re: Next maintenace release

[Peter B. West]

Christian Geisert wrote:

> Ok,
>
> as a lot of people want a date for the next release I propose 1st
> of june as target date for the release candidate for 0.20.4
>
> What do you think?


Christian,

OK by me. Anyone have any specifics he or she wants to get into the release?

Peter


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

Re: Identity crisis on cvs.apache.org?

[Peter B. West]

Joerg,

Thanks.  It seems there were some configuration changes in openSSH 
between versions.

Peter

J.Pietschmann wrote:

> I don't see anything unusual (Win2K, cygwin OpenSSH). It could
> be that your ssh client has changed default settings. My ssh uses
> known_hosts for storing identities, perhaps known_hosts2 indicates
> SSH2 protocol or whatever. You could try to force your client to
> try SSH2 or SSH1 first, or copy known_hosts2 to known_hosts, or
> simply kill the file.
>


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

build changes

[Peter B. West]

Ladies and gentlemen, boys and girls,

What's the state of play now with the changes to the build system?  Has 
the elimination of Xalan1 been completed?  Who's doing what there?

I am planning to throw a branch off HEAD to tinker with at least the 
versioning information for the build.  I would like to try that before 
0.20.4, if possible.  What's the expectation with 0.20.4?

Peter


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

Identity crisis on cvs.apache.org?

[Peter B. West]

Fopsicles,

I have just gone through the usual upgrade agony of RedHat (7.0->7.3) 
with the added spice of a switch from Gnome to KDE after an abortive 
flirtation with Nautilus.  Having paid my debt to society (or so I 
thought), I tried to perform a `cvs update' on the maint branch.  I 
received in response the following:

The authenticity of host 'cvs.apache.org (63.251.56.143)' can't be 
established.
RSA key fingerprint is 51:85:7d:8f:57:54:e7:6f:27:26:98:7a:c7:c1:47:87.

However, if I keyscan cvs.apache.org, I get the same key back as is in 
my ~/.ssh/known_hosts2 file.

Has anyone else seen this, or is it another artefact of my upgrade?

Peter


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

Re: Latest FOP schema

[Peter B. West]

Joerg,

Comments below.

Joerg Pietschmann wrote:

>"Arved Sandstrom"  wrote:
>  
>
>>I think the predominant opinion is (assume all of this fits on one page) -
>>
>>a normal block area (generated by the outer block) that contains:
>>
>>one or more line areas for "level_0_text fills to position A";
>>then a block area with one or more line areas for "level_1_text positioned
>>at A fills to position B";
>>finally more line areas for "more level_0_text positioned at B".
>>
>>Note that if your example had been
>>
>>
>>level_0_text fills to position A
>>level_1_text positioned at A fills to position B
>>more level_0_text positioned at B
>>
>>
>>then it would still be the same.
>>
>>
>
>As a side note, assuming western language and script and hyphenation
>off, if the example had been
>
> 
> level_0_text fills to position
>  Alevel_1_text positioned at A fills to position B
> more level_0_text positioned at B
> 
>
>it is probably illegal, according to 4.7.2, Point 3. I suppose
>it would be illegal to have a line break within the word
> "Alevel_1_text"
>here. The problem here is, where do I get the rules whether a line
>break is permitted somewhere for a certain language and script? And
>how is this supposed to deal with "out of context" stuff like product
>numbers or artificial DB keys or programming language identifiers
>containing underlines and dashes, and with non-breaking spaces, odd
>symbols, and character abuse (uppercase greek omega instead of Ohm
>sign)? Again, I suppose the burden has to be put on the user who
>has to ensure everything is correct, including changing the current
>language for quotes, nested if necessary, and specifying a language
>for product numbers and programming language ids. Umm, something
>looking like
>  ..., ISBN 0-201-48345-9...
>and
>  the org.apache.fop.render.pdf.Font
> class implements the   language="x-Java">org.apache.fop.layout.FontMetric
> interface ...
>
>This would eleminate some keep-together stuff, I guess, but most
>probably requires a mechanism to teach the processor line breaking
>rules for user defined languages.
>
>
>- Is the interpretation reasonable? (I don't ask about correctness...:-)
>- Can the redesigned FOP deal with the "Alevel_1_text" above, I mean
>  will it raise an error or warning?
>- Can/should FOP deal with user supplied word/line breaking rules?
>
>
>Note that the same applies to the recently heavily discussed problem
>of a block level element inside an fo:inline, according to 4.7.3, in
>particular point 3.
>  
>

My take on this would be that the fo:block, by definition, breaks the 
line. The question of whether this is an allowable place for a line 
break is pre-empted by the user's assertion that it is. In these 
circumstances, point 3 does not come into play.

The larger question of where line breaks are allowed in specific 
languages and scripts is addressed by Unicode/ISO 10646. See, e.g., 
. Unicode 
characters are assigned character properties in the Unicode Character 
Database (UCD), the individual files of which are available under 
 or 
. These cover such categories as 
Case, Numeric Value, Dashes, Line Breaking and Spaces. This will be the 
mechanism for teaching FOP how to handle line-breaking. Hyphenation will 
also, I imagine, have to take account of the UCD.

The "special languages" that you mentioned would probably be dealt with 
by taking advantage the sets of semantically differentiated characters 
which tend to share the same glyph. The most immediate example is the 
set of spacing characters which include U+0020 and U+00A0 non-breaking 
space. There is also a non-breaking hyphen, and raised dots with 
different semantics. So my bottom line there would be that, at least for 
the immediate future, we should concentrate on implementing the UCD as 
fully as possible where it impacts on layout, and let users with special 
requirements work out how to express them in Unicode.

I have a copy of Version 2.0 of The Unicode Standard, and only regret 
not having Version 3. I can heartily recommend the book, if only for the 
pleasure of the fonts.

Peter


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

[Fwd: Inline-building]

[Peter B. West]

  Devs,

Forwarding request I sent to the xsl-editors.

Peter

 Original Message 
Subject: Inline-building
Date: Tue, 07 May 2002 00:35:26 +1000
From: "Peter B. West" <[EMAIL PROTECTED]>
To: xsl-editors <[EMAIL PROTECTED]>



Editors,

There has been considerable discussion on the fop-dev mailing list about 
the handling of fo:blocks occurring within fo:inline or fo:basic-link 
elements within a parent fo:block.  This discussion has centered on the 
interpretation of 4.7.3 Inline-building.  Does the attached diagram 
represent the correct handling of the situation?  If not, please clarify 
the situation.  In any event, any clarifying comments would be appreciated.

Peter B. West





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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arnd,

I just tried the 642 build, and it does export SVG.  Unfortunatley, it 
does not import.

Peter

Arnd Beißner wrote:

>Editing SVG with Adobe Illustrator 10 works ok (small wonder), though the 
>licence is
>fairly expensive if you don't use it regularly. The drawing app in 
>OpenOffice may
>have SVG export, too - I heard, but didn't check myself.
>
>  
>



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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

Again, I agree that, in the conceptual area tree described in the spec, 
blocks embedded in inline-area generating FOs in the fo tree (e.g., 
fo:inline and fo:basic-link), themselves embedded in a parent fo:block, 
do not bubble up to the same level as the parent fo:block.  Going back 
to your diagram, I am talking about the fo:block embedded in the 
basic-link.  I have attached another diagram describing a subset of your 
original example.

Let me clarify what I meant by the term "bubble up" in the reply to Karen.

"Then what seems to me to be the *intention* that layout within 
fo:inline and fo:basic-link proceed as though these wrappers were 
layout-transparent, would be made clear. That is, blocks bubbling up 
from below will be stacked in the BPDir without IPDir attachments from 
surrounding inline-areas."

This refers to the spec's conceptual area tree.  It arises out of my 
misapprehension that the nesting of fo:blocks within inline-area 
generators would involve a nesting of the layout within the generated 
inline-area.  The fo:inline inline-area in the area tree would grow 
within the bounds of the containing line-area and block area, but 
limited by it.

It doesn't work that way, though, as we have all discussed.  These block 
areas "bubble-up", not in terms of their containment within the 
appropriate set of line-area->inline-area->block-area, bu in terms of 
their layout consequences.  Apart from any layout-altering properties 
defined on the containing inline-area generator, e.g.font or border 
changes, the text and any nested blocks are treated for layout as though 
they had occurred as direct children of the outer fo:block.  That's what 
the term "layout-transparent" means.

That, at least, is what I take the *intention* of the authors to be. 
 And that is why I want to see some clarification of the relationship 
between 4.7.2 Line-building and 4.7.3 Inline-building.  It seems to me 
that the spec decrees that the initial text of the basic-link ("In 
basic-link " in my example) is constructed into an inline-area by the 
Inline-building process of 4.7.3.  In order to do this, it has to know 
about the constraints that it inherits from the already partially 
constructed line-area which contains "Text in block ".  It seems to me 
that, conceptually at least, in the conceptual area tree model of the 
spec, the inline-building process needs to take account of all of the 
glyph substitution, insertion and deletion considerations that apply to 
4.7.2, because it is now the responsibility of the inline-area generator 
to generate a *single* inline-area to complete the pending line-area of 
the parent.  To do that, it will have to be able to do its own 
line-breaking.

Clarifying this is a matter of the coherence and consistency of the 
spec.  It is also important if you are tempted, as I am, by the idea of 
mimicking this conceptual model and procedure in actual code.

All of the above may just mean that, while I thought I had been brought 
around to your way of thinking on this aspect of the spec, I may still 
be thinking about it very differently.

Peter

Arved Sandstrom wrote:

>My last post was motivated by one thing - the statement that a block area
>"bubbles up". Well, it does not, not in the conceptual area tree described
>in the XSL spec. As a result I thought it worth our time to ask for some
>specificity when the area tree being referred to is not immediately obvious.
>
>I agree with your sentiments, particularly the last sentence. As such I
>think it is very important to establish exactly what area tree we are
>talking about in any given context. In theory there are at least 2 - the XSL
>1.0 conceptual area tree, and the real "tree" (really, whatever structure we
>happen to use). There could be more.
>
>  
>




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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

I agree that there is no need to tie the rendering to any particular 
model, as long as the results are equivalent.  The discussions that span 
this list and the Xslfo-proc-devel list testify that there are many 
approaches to process of layout.  However, if I am reading this 
correctly, the proposal is to clarify the text of the spec.  In that 
context, the treatment of the area tree and its relationship to the fo 
tree must be coherent and consistent, or we will be in even deeper 
difficulties.

Peter

Arved Sandstrom wrote:

>> From what I see here you are changing the shape of the tree.  The
>>motivation seems to be to make it explicit that block areas contained
>>within an inline area must bubble up to become direct children of the
>>containing block area.  I can't see that that is feasible, given the
>>basic design principle of the spec that the area tree follows the fo
>>tree.
>>
>[ SNIP ]
>
>With respect to the second sentence of the above, I think we should be very
>clear at all times about exactly which area tree we are talking about - the
>conceptual area tree as described in the spec, or the real one constructed
>by Fop.
>



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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Keiron et al.,

Just a quick reaction to this - I'm off to sit next to the footpath 
reading the newspapers and drinking tea.

 From what I see here you are changing the shape of the tree.  The 
motivation seems to be to make it explicit that block areas contained 
within an inline area must bubble up to become direct children of the 
containing block area.  I can't see that that is feasible, given the 
basic design principle of the spec that the area tree follows the fo 
tree.  Specifically, by doing that, you lose what Karen called, iirc, 
the semantic markers of the enclosing inline-area, e.g., fo:inline or 
fo:basic-link.  So how does that semantic information get to the 
once-but-no-longer enclosed fo:block?  It is possible to arrange the 
transfer of such information to the block-area in the area tree, but 
then the inheritance becomes a purely algorithmic thing, and the 
structural link between the fo tree and the area tree is broken.

It seems to me that one reason for the murkiness in this area of the 
spec is that the authors are at pains to preserve this structural 
relationship, while at the same time ensuring that the actual layout is 
determined in the way you propose.  I think that it's possible to do 
this by clarifying the particular issues about line-building and 
inline-building in this context.

The bottom line is that I think we have to clarify the text so that it 
comprehensibly expresses the situation laid out in Arved's original 
diagram of the handling of the fo:block within an fo:basic-link within 
the text of an fo:block.

Peter



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

Re: properties

[Peter B. West]

Karen,

I was your opinion that I was most concerned about on this one. I, for 
one, am quite happy to hold off to give you more time to make an 
argument. Part of my point was that it *was* in pretty good shape the 
first time around.

Peter

Karen Lease wrote:

>Not really. As a fairly interested party, I must admit that mentions of
>throwing it out and starting over don't leave me totally indifferent,
>but I've got little enough time as it is for FOP these days, and I'm
>trying not to let myself be distracted.
>In any case, we all know that it's never right the first time around.
>
>  
>



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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

My apologies. I was just taking the opportunity to think aloud about 
aspects of the interaction between inline-areas and block-areas. Trying 
to make sense of the various elements of the spec leaves your ears buzzing.

Peter

Arved Sandstrom wrote:

>>>For the record, I disagree with Arved's reading of Line-Building. I read
>>>4.7.2, point 5 as saying that a block area generated by an fo:block can
>>>contain a mixture of block areas and line areas.
>>>
>>>  
>>>
>>Agreed. In fact, it seems to me that the line-area is a pseudo-block
>>designed to maintain the condition that the all of the children of an
>>area must be of the same type, in the circumstance where there will
>>clearly be block children of an fo:block, and to allow for simple block
>>stacking in the BPDir. There is no need to wrap block areas in a
>>line-area.
>>
>>
>
>On that last point let me clarify and point out that I never suggested that.
>By definition a line area is a block area that contains only inline areas as
>children.
>
>The quibble was over whether block areas returned/generated by by FO
>children, and line areas that wrap inline areas returned/generated by FO
>children, can/must/shouldn't co-exist in a single normal block area
>generated by the top-level block FO. I was suggesting the "shouldn't"
>viewpoint; Karen reads it differently.
>
>  
>



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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Keiron,

Keiron Liddle wrote:

> I'm almost thinking of going a step further.
> Maybe we could add annotations to the spec to clarify these things 
> with our understanding and then present this information. 

Yes indeed.  And an index, including especially a concept index.

>
> It seems to me that the spec writers are not as involved as they 
> should be. 


Peter



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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

This is a good idea. I half-heartedly suggested as much to Matthew 
Huggett when he asked what a non-programming technical writer might 
contribute. It requires too deep an insight into the spec, but he (or 
Cyril) may of some assistance to you.

What would be even more generally useful would be to get the spec 
editors to put up a site, possibly with disclaimers plastered all over 
it, to which they post FAQs on the spec. They must get a lot of 
repeating questions from the various parties who are trying to 
implement. I'm not subscribed to the xsl-editors mailing list (which I 
suppose I should be.) Is anyone else subscribed? If so, have requests 
like this been made before?

Peter

Arved Sandstrom wrote:

>Hi, Keiron
>
>I think what I should do is establish a section on the website with all the
>other design notes that is a central location for these kinds of studies.
>This could be the first one. I can undertake to start churning these out on
>a fairly regular basis - I think we need them.
>
>Once they are in CVS then it would be easier for others to annotate them,
>modify them, and what have you. We'll have to settle on a mutually agreeable
>figure format so as not to unduly restrict access.
>
>As far as the spec goes, absolutely, I agree. That's why I think that these
>diagrams help so much - in order to draw them you must work your way through
>the spec in detail. The process also exposes any gotchas before too much
>code has been written based on different assumptions.
>
>I'll proceed on the above basis and set up a place for these
>diagrams/studies, and crank out some more. I am somewhat reluctant to do any
>coding at the moment until such a time (hopefully not far away) where I am
>satisfied that I understand the new design well.
>
>Arved
>
>  
>
>>-Original Message-
>>From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
>>Sent: May 2, 2002 6:18 AM
>>To: [EMAIL PROTECTED]
>>Subject: Re: [REDESIGN] Line layout manager discussion
>>
>>I agree with you (except for the last statment about one line).
>>
>>I found this statement interesting:
>>6.6.7. fo:inline
>>
>>"An fo:inline that is a child of an fo:footnote may not have block-level
>>children. An fo:inline that is a
>>descendant of an fo:leader or of the fo:inline child of an
>>fo:footnote may
>>not have block-level children,
>>unless it has a nearer ancestor that is an fo:inline-container."
>>
>>It suggests that what you are saying is correct and that block-level
>>elements create a block area outside the immediate line area. So
>>to have a
>>block area inside a line area you must use the inline-container, a block
>>is never automatically embedded.
>>
>>
>>Also in this section, reading between the lines (it's amazing how they
>>manage to contradict themselves in such a short section)
>>
>>4.7.3. Inline-building
>>
>>An inline fo element with a block element as a child will create inline
>>areas and return the block area.
>>It will create a single inline area that can fit consecutive child inline
>>areas on a single line. So the child inline areas are put into parent
>>inline areas that are separated by line breaks and block areas.
>>
>>So Karen's approach is looking better.
>>
>>I really wish this spec would say relevant things in the right places and
>>mention how everything is handled rather than being so vague.
>>
>>
>
>
>-
>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] Line layout manager discussion

[Peter B. West]

Karen,

Comments below.

Karen Lease wrote:

>Arved, Keiron et. al.
>
>I guess logically it's true that the blocks nested in inlines should be
>wrapped in inline areas, but it makes me nervous :-)
>At least they cause line breaks, that much seems sure. I still think
>that we should put pressure on the spec editors to either get rid of
>structure or clarify it in the next version (ha, ha). If people need
>blocks in inlines, they have inline-container.
>
>In fact, I'd like to think that the possibility of including block-level
>FOs in inline-level FOs is purely for convenience or "semantic nesting"
>and should not really affect the area tree, except to cause line breaks
>before and after the block areas.
>
>The most legitimate use I can see for this kind of semantic nesting is
>basic-link, because it could spread the link semantics over several
>areas; kind of a link-wrapper.
>
>-
>
>For the record, I disagree with Arved's reading of Line-Building. I read
>4.7.2, point 5 as saying that a block area generated by an fo:block can
>contain a mixture of block areas and line areas.
>
Agreed. In fact, it seems to me that the line-area is a pseudo-block 
designed to maintain the condition that the all of the children of an 
area must be of the same type, in the circumstance where there will 
clearly be block children of an fo:block, and to allow for simple block 
stacking in the BPDir. There is no need to wrap block areas in a line-area.

>Also, if we look at 4.7.3 (inline-building), I find it curious that it
>starts by saying TWICE that an inline FO places inline areas and anchor
>inline areas returned by its child FOs in inline areas which it
>generates, and then suddenly throws a block-area into the condition
>described in point 1. Looks more like a hasty copy/paste from the list
>for Line-building!
>
It's not just curious, it's contradictory. I have come around to Arved 
way of thinking on the behaviour of blocks in inline-areas, but the only 
way that I can see to do it is to change the relevant part of 4.7.3 to read:

An inline-level formatting object F which constructs one or more 
inline-areas does so by placing normal inline-areas *and/or normal block 
areas* and/or anchor inline-areas returned to F by its child formatting 
objects as children of inline-areas which it generates.

Then what seems to me to be the *intention* that layout within fo:inline 
and fo:basic-link proceed as though these wrappers were 
layout-transparent, would be made clear. That is, blocks bubbling up 
from below will be stacked in the BPDir without IPDir attachments from 
surrounding inline-areas. This will be guaranteed by the partitioning 
arrangements of 4.7.3. The difference from 4.7.2 will be that these 
blocks will be wrapped in an inline-area generated by the fo:inline, 
which will in turn be wrapped in a line-area, exactly as per Arved's 
diagram.

However, as far as I can tell, this last level of wrapping is done by 
the parent fo:block in the process of laying out the inline-areas that 
are being returned by the the fo:inline. The decision to return a 
separate inline-area wrapping a block-area is made entirely by the 
fo:inline (or fo:basic-link). By the time the block gets to the parent 
block for layout, it is an inline area, and the only reason it is laid 
out in its own line-area is the constraint (from 6.6.7 fo-inline) that 
"no area may have more than one normal child area returned by the same 
fo:inline formatting object." The same constraint applies to fo:basic-link.

This leaves a question about where hyphenation is decided. In 4.7.2 
point 5, there is a discussion about glyph substitution, insertion and 
deletion which seems to assume that the sequences of inline-areas being 
built into line-areas are in fact fo:characters. The corresponding 
sequences bubbling up from fo:inline and fo:basic-link are already 
wrapped as integral inline-areas and presented as a fait accompli to the 
parent line-builder.

The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim 
information in order to present sane integral inline-areas to its 
parent, and to allow for the layout of nested fo:blocks. (This is pure 
hierarchical galley stuff.) In any case, there should be a correspondent 
in 4.7.3 to the discussion of substitution, insertion and deletion in 
4.7.2, just to make it clear what the responsibilities of the 
inline-builder are. That's if I have this right, this time. What do you 
think?

>As Keiron says, if the spec writers had been clearer, we wouldn't have
>to spend hours chasing our tails like this!
>
Or, alternatively, if they would clarify these questions in a timely manner.


Peter


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

Re: properties

[Peter B. West]

Hello devs.

Does the near-silence on this one signify consent?

Peter

Keiron Liddle wrote:

> Hi Peter and others,
>
> What is the status of property handling?
>
> Are we going to go with Peter's suggestion and commit the java source 
> to cvs and work on handling properties fully from there?
>



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

Re: Anything for a non-programmer to do?

[Peter B. West]

Matthew,

I've moved this to fop-dev.  Look over the documentation that we have 
(basically, the web site html) and see what you think.  As a 
non-programmer, you will be mainly interested in the user perspective. 
 How much of a non-programmer are you?  If you can grok the code at all, 
your input on the Understanding section, which Cyril Rognon is currently 
collecting and html-ifying, might be appreciated.

Have you read the spec?  This is a tall order, but I think it would be 
useful if a writer with some understanding of the spec could monitor the 
design discussions and, referring them back to the spec, develop a 
series of notes - like annotations on the spec - which unified the often 
scattered references in the text on certain difficult issues.  If you 
are subscribed to fop-dev, you will have seen the recent discussions on 
layout and line-area handling.  Related to that is the gradual 
building-up of a form of "concept index" into the specification, perhaps 
in the form of a FADesignQ.  More simply, a series of precis on the 
design discussions about controversial, or just plain difficult, areas, 
summing up the points of view and the eventual, one hopes, resolution.

Does any of this appeal to you?

Peter

Matthew Huggett wrote:

> Hi:
>  
> Is there anything that a non-programmer can do to help the FOP 
> project? I'm a technical writer.  Is there anything involving 
> documentation that needs to be done?
>  
> Matthew




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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Arved,

Firstly, thanks for taking the trouble to do this.  Your diagrams make 
your argument beautifully clear, and facilitate discussion for everyone, 
even XSL spec novices.  Even me, who struggles to follow text-only 
arguments.  I haven't followed all of the posting yet, but one question 
has come up for me already.

Look at

a paragraph of text with a block and more 
text

What about the restriction that a given area's children must all be of 
the one type (4.2.1 Area Types)?  Doesn't that oblige us to wrap the 
block within an inline?  Then that inline wrapper can sit in sequence 
with the inline-areas 't', 'e', 'x', 't', ' ', as indeed the basic-link 
inline-area already sits in sequence with 'S','o','m','e',' 
','t','e','x','t',' '?

What's your take on this?

N.B.  I have attached the SVG generated by Dia.  I don't know what the 
quality is like, but if the quality of the generated PNG is anything to 
go by, probably not too good.  If we can all get access to a reasonable 
SVG vector editor that will write PNGs, we will be able to pass the 
editable file around as well, which will greatly facilitate this sort of 
discussion.  Any candidates for a linux-enabled SVG editor?

Peter

Arved Sandstrom wrote:
...

>a) There are no block-level children of the top block, only inlines, so we
>know that the one or more block areas generated by the top-level block are
>going to contain line areas. Because of the page break there are 2 normal
>block areas generated by the top-level block;
>
>b) "some text" is simple - the inline goes neatly into the first line area
>as its first child;
>
>c) Now we hit the basic link. This generates one or more normal inlines,
>which are outlined in orange. The "a paragraph of text" is the first inline
>child of the first normal inline area generated by the basic-link;
>
>d) we hit the nested block. OK, this is where the anguish starts. :-) It
>produces at least one normal block area, by definition. I have given this a
>pale green background. This _cannot_ occupy the first normal inline area
>generated by the basic-link, because that already contains an inline area
>(rule 1). So it must be in a second normal inline area generated by the
>basic-link. By rule 3, the first line area may not contain 2 areas generated
>by the same inline, so that's why we terminate line aea 1 and start another;
>  
>





http://www.w3.org/TR/2000/CR-SVG-2802/DTD/svg-2802.dtd";>

  outer block line-area
  basic-link inline-area
  glyph inline-areas
  inline 
inline-area
  inner block block-area
  
  
  
  
  
  
  
  
  
  S
  
  
  o
  ...
  
  
  x
  
  
  t
  
  
  
  
  a
  
  
  r
  
  
  a
  
  
  p
  
  
  
  
  
  a
  ...
  
  
  x
  t
  
  
  
  
  
  
  
  Block details
  .
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  




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

fop 19

[Peter B. West]

Does anyone know what happened to fop 19?  Did the tag go away?  It does 
not show up in a cvs status of build.xml.  I ask because the starting 
point for my code was 19, and I would like a point nearby to branch from 
for my initial migration.

Peter


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

Re: [REDESIGN] Line layout manager discussion

[Peter B. West]

Keiron Liddle wrote:

> Karen,
>
> On 2002.04.29 22:39 Karen Lease wrote:
>
>> It's certainly true that mixing blocks in inlines, as the spec says is
>> allowed, gets very complicated. I remember some discussion of this on
>> the list a long while ago and I think we actually asked the XSL editors
>> what kind of areas they imagined this generating, but never got an
>> answer. If I understand your idea correctly, the layout areas you would
>> generate from this example are the ones I would like to generate also.
>> (Block area containing some lines, nested block, more lines, nested
>> block and more lines.)
>
>
> Yes. Basically the same as having a block among text inside a block. 
> Although I don't know what would happen with non-inheritable 
> properties like background.
>
>
>> *** I think this is clearly the key issue to decide in this round of
>> discussions: flattened or nested.
>
>
> I think it is possible both ways but not necessarily easy.
> I noticed in the spec it says inline areas may have inline area 
> children but its content rectangle and axamples seem a bit different 
> from what we are talking about here.


K & K,

I think it will necessarily be both, as your discussions are tending to 
show.  If so, which is easier: generating flattened areas from trees, or 
generating trees from flattened areas?  No contest.  My notes on 
galleys, keeps and spaces may be relevant here.

Incidentally, I have always been a bit surprised that the spec authors 
did not attempt a fully recursive definition within page viewports.  It 
really is a page-oriented spec.

Peter


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

Re: [Fwd: Re: no more spam or virus but attack]

[Peter B. West]

Oops. Sorry about that. That was supposed to go elsewhere.

Peter



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

[Fwd: Re: no more spam or virus but attack]

[Peter B. West]

  Sirs,

And this alternative response.

Peter

 Original Message 
Subject: Re: no more spam or virus but attack
Date: Mon, 29 Apr 2002 18:06:52 +0200
From: Martin Kraemer <[EMAIL PROTECTED]>
To: GOMEZ Henri <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>



On Mon, Apr 29, 2002 at 05:40:41PM +0200, GOMEZ Henri wrote:
> Hi to all,
> 
> I just received this email, with fake from header
> of Christopher Cain.
> 
> The subject is about jni worker, and attached file
> included a httpd.exe.
> 
> that's no more a spam or virus but a 'human writen'
> mail caming from someone who track our tomcat-dev list.
> Someone who know about tomcat, httpd, jni and worker.

I disagree. I got similar virus-loaded mails from all over the
world, many (apparently) sent by by ASF members, and carrying
titles referring to ASF topics.

This virus-bot (I think) picks up its keywords from the various
HTML pages we have, and adds some "dressing" to make a nice
Subject (like: You are done, the , or
'Undeliverable mail--""') using mailto: links
from the same page, or belonging to the same site.

Some mails I presumably got from Ralf Engelschall:
  [EMAIL PROTECTED]  A  WinXP patch
  [EMAIL PROTECTED]  A  powful tool
from Marc (sic!)
  [EMAIL PROTECTED] W32.Klez.E removal tools
  
or from
  [EMAIL PROTECTED]   Undeliverable mail--"Apache HTTP Server Version 1.3"
  [EMAIL PROTECTED]   Undeliverable mail--"ACCESSKEY"
  [EMAIL PROTECTED]   Undeliverable mail--"by mod"
  [EMAIL PROTECTED]   Returned mail--"bgcolor"
(in this case it's most obvious: such a syntax is ONLY used by viri)

*ALL OF THESE* exploit the same multipart/alternative bug of
M$/Outlook which executes dynamic content without asking.

> What could we do against that ?
> 
> - Commiters PGP to signe messages ? 
>   It works for many mail readers even M$ one but not 
>   for Netscape Messenger .
> 
> - Ask all of us to be very very carefull when receiving
>   mail with attached files, even if the From header appears
>   to be from someone known.

No problem for me. Zilch, none nadda. I read my mails on FreeBSD.
Also, I added amavis + nai uvscan so that the other users on my
machine don't get infected ;-)  and I use up less space in my spam-mailbox.

   Martin
-- 
 | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany




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

Re: Time zones

[Peter B. West]

Rhett,

Let's try again.

> You're only an hour away from Arved, so you may be OK anyway.
>
> Ft. Lauderdale Mon 10:27am +0
> Halifax Mon 11:27am +1 

London Mon 3:27pm +5
Paris Mon 4:27pm +6
Frankfurt Mon 4:27pm +6

> Brisbane Tue 12:27am +14
>
> Peter




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

Time zones

[Peter B. West]

Rhett,

You're only an hour away from Arved, so you may be OK anyway.

Ft. Lauderdale   Mon 10:27am  +0
Halifax  Mon 11:27am  +1
London   Mon  3:27pm  +4
ParisMon  4:27pm  +5
FrankfurtMon  4:27pm  +5
Brisbane Tue 12:27am +14

Peter

Rhett Aultman wrote:

>I live in the US.  Florida, to be exact.  I'd like to be able to attend and be a part 
>of chat meetings, but I realize that I'm small potatoes on this project, so my needs 
>should be secondary.
>
>  
>



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

Notes available on web page

[Peter B. West]

Fop-devs,

It appears that I do not have an account on daedalus yet anyway.  Many 
thanks to the anonymous indivdual who re-published the web site. 
 Although there are some niggling menu problems, my notes-in-progress 
are now, at least, available.

http://xml.apache.org/fop/design/alt.design/keeps.html has my initial 
notes on keeps data structures, as I posted to the list earlier.
http://xml.apache.org/fop/design/alt.design/spaces.html has notes on the 
parallels and differences between the linking structures necessary for 
keeps and space-specifiers.  It deals only with block stacking 
constraints at this stage.  Joerg, this is the one I was talking about 
earlier.
http://xml.apache.org/fop/design/alt.design/galleys.html and
http://xml.apache.org/fop/design/alt.design/footnotes.html were 
committed some time ago, and would have been available in individual 
builds, but this is their first appearance on the web site.  The same 
comments apply to 
http://xml.apache.org/fop/design/alt.design/compound-properties.html and
http://xml.apache.org/fop/design/alt.design/traits.html which are simply 
convenience lists.

Peter


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

Re: Committing html

[Peter B. West]

Arved,

Thanks.  I wionder what I can do to re-gruntle Brian?

Peter

Arved Sandstrom wrote:

>You'll get a disgruntled reply from Brian if you actually asked him on his
>personal email. :-) Stuff like this it's best to go to [EMAIL PROTECTED];
>typically you'll end up talking to Manoj Kasichainula.
>
>  
>



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

Re: line layout commit

[Peter B. West]

Arved,

See comments below.

Arved Sandstrom wrote:

>1. I can see a place for structured (that is, planned) communication:
>conference calls, scheduled meetings on a system like Peter describes, use
>of something like MSN Messenger, setting up an IRC channel and everyone
>getting together there. But I don't think that's the problem at the moment.
>  
>
The problem is going to be with the timing. Scheduling a regulat chat 
would be a good idea because folks can try to schedule around that and, 
who knows, it could get to be a habit.

>2. Can we do better with CVS? ,,, If we used watches, we could
>set things up so Karen might get notifications on 'cvs edit' for
>such-and-such a package, Peter might get 'cvs edit' notifications on another
>package that he selects, and so forth, whatever is of interest.
>
>This would at least give us notifications at the other end of the process,
>which is when a developer (say, Keiron) _starts_ to work on a file.
>
>This is a bandaid, though. I am just as bad as Karen when it comes to
>wanting to have everything just-so before I check something in. This is OK
>with reserved checkout systems like SourceSafe default, but it's lousy for
>the unreserved checkout CVS case.
>  
>
Yes and no. I think that the motivation for the CVS model was 
dissatisfaction with the RCS/SCCS lock model in precisely these 
situations; multiple developers, with some in the process of lengthy 
modifcations. I'm with you and Karen on this. My flesh creeps at the 
idea of committing code which I know to be in a shambolic state. It's 
worse if I have to then merge in someone else's changes, then iterate 
over the whole process a couple of days later.

The situation is worse at the moment because basic design issues are 
being worked out on the fly, so there are going to be large, 
incompatible areas of the code between Karen and Keiron until the design 
is settled. My design is even more incompatible, so when I check my code 
in, I will be setting up my own branch. It seems to me that Karen might 
productively branch her changes, and track what Keiron is doing by 
merging in from his code. Take the current issue with her subclassing of 
Keiron's code. She need not have the code commented out in her branch, 
and she can explore the issues in safety. When she has proven the 
concept, she can merge back into the trunk. I don't think she is going 
to be left behind, but if she cannot develop her ideas in relative 
isolation from other ongoing and incompatible changes, a lot of her time 
may be spent in tedious merging activity.

>I would nevertheless suggest maybe trying the watch features.
>
Agreed

>What we lack is ownership. We've got a whack of committers and a fair-few
>active ones, and maybe it's now time to allocate ownership of stuff on both
>branches. Ownership does _not_ mean you are the only person working in that
>package or packages - what it means is you are the POC for work being done
>in that package. You are the arbiter of disputes. We could even combine this
>with BugZilla ownership, possibly.
>  
>
The only trouble I see with this is that the only ones who are really 
familiar with the code are also *very* busy with development, part-time.

Peter


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

Committing html

[Peter B. West]

Fops all,

I have committed changes to the web site into 
xml-site/targets/fop/design/alt.design and I would be most grateful if 
one of the committers could perform a cvs update on xml.apache.org. 
 Why?  Having set up ssh on cvs.apache.org, I promptly forgot my login 
password.  Keiron, don't say a word...  I have asked Brian to reset the 
password, but I don't know how long this will take.

Tia,

u Peter!


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

Re: Insufficient Karma!

[Peter B. West]

A pox on Google, I say!

Peter

P.S. (Eventually fixed by changing all of my CVS/Root entries from 
/home/cvspublic - left over from a previouos checkout - to /home/cvs).

J.Pietschmann wrote:

> J.Pietschmann wrote:
>
>
> Ah, found (out of >4000 google hits for "insufficient karma"!)
>  http://www.mail-archive.com/poi-dev@jakarta.apache.org/msg00382.html




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

Insufficient Karma!

[Peter B. West]

Fop-devs,

I just tried to commit a file I had added.  Result:

 Access denied: Insufficient Karma 
(pbwest|xml-fop/docs/design/alt.design)
cvs server: Pre-commit check failed

It looks to have something to do with the avail file, and access to a 
resource called 'id'.

Any ideas?

Peter


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

Re: line layout commit

[Peter B. West]

K, K, A and other developers,

Regular chat sessions would probably have been useful here, and I think 
that they might still be useful. Probably every interested party but me 
is in the time zone spanned by Keiron and Arved. Anyone in the US? It 
should be possible for you to arrange some times. I would love to 
eavesdrop, and I would try to attend. What times would suit the three of 
you? Do you think it would be useful?

Peter

Karen Lease wrote:

>Hi Keiron,
>
>On the one hand, I'm happy to see new work in the LayoutManagers.
>
>On the other hand, it turns out, I have been plugging (unfortunately
>really slowly) away at the Break Possibility ideas I mentioned a while
>back and just this very evening I had gotten the Line and Text
>LayoutManagers to where they were actually generating areas based on the
>BreakPoss ... and maybe it was ready for CVS.
>
>... really I'm not kidding.
>
>That was when I discovered that you had beat me to it by a few hours. I
>only saw your "thinking aloud" mail last night and my feeling was that
>apart from the "flattening of inline LM" idea, there might not be such a
>big difference in our approaches. But of course, the code itself is
>quite different.
>
>
>Arved Sandstrom wrote:
>  
>
>>Very cool. I will try to pry away from my other project and also doing my
>>income taxes and put in some quality time checking this out this weekend.
>>Sounds like we are basically at the point where a bunch of us can usefully
>>pitch in. :-)
>>
>>
>>
>>>-Original Message-
>>>From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
>>>
>>>Hi Developers,
>>>
>>>I just committed a bunch of changes to the line layout.
>>>I think it now has a reasonable basis to further develop the inline level
>>>areas and build line areas.




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

Editable image formats

[Peter B. West]

Developers all,

I have taken to using xfig for my design diagrams, and I would like to 
include an editable form of the images in the CVS.  xfig will export 
Postscript, Encapsulated Postscript, PDF, LaTeX, IBM/HPGL, T/PIC, CGM, 
but not SVG.  Are any of those suitable for downline vector editing?

Peter

P.S. What's the difference between PS and EPS?


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

Re: Lest we forget

[Peter B. West]

Todd Pierce wrote:

>Clearly Peter B West is an Australian or New Zealander who should have been
>enjoying a public holiday. Why he chose to post this message to the FOP
>developers list, however, is a total mystery.
>
Todd(.au),

Surely not "total"?

Peter


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

Re: Using CVS tags

[Peter B. West]

>
> ***WARNING*** Jars and class files checked into CVS must have their 
> '-k' flag defaulted to 'o' - original value at checkin - to prevent 
> corruption of binary files.  I don't know whether this is critical for 
> class files, but I would not treat them as binary files.


Should read, "... but I *would* treat them as binary files."

Peter



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

Lest we forget

[Peter B. West]

Age shall not weary them, nor the years contemn.
At the going down of the sun, and in the morning,
We shall remember them.

Lest we forget.
Anzac Day 25th April 2002


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

Using CVS tags

[Peter B. West]

Fops,

Some more comments on ways of using CVS tags.

At present, we are using the trunk for ongoing development.  We have a 
*branch*, fop-0_20_2-maintain, and a release tag, fop-0_20_3.  Branch 
tags name a branch off the trunk (or off another branch.)  Every version 
of every file on a branch will be tagged with the branch tag.  Release 
tags name one particular revision of each file in the tagged release 
set, so only one possible version of each file can be associated with a 
release tag.  As it happens, the versions tagged with the release tag 
fop-0_20_3 are on the tagged branch fop-0_20_2-maintain.

Issuing 'cvs status -v build.xml' at the xml-fop module level of a tree 
checked out with "-r fop-0_20_2-maintain" shows (inter alia)

   Working revision:1.44.2.11
   Repository revision: 1.44.2.11   /home/cvspublic/xml-fop/build.xml,v
   Sticky Tag:  fop-0_20_2-maintain (branch: 1.44.2)

   Existing Tags:
fop-0_20_3  (revision: 1.44.2.8)
fop-0_20_2-maintain (branch: 1.44.2)
fop-0_20_0  (revision: 1.37)

I.e., the development in the fop-0_20_2-maintain branch includes the 
fop-0_20_3 release.

The macro text associated with the *particular*, or release, tag of a 
file is "$Name".  Files checked out using the "-r fop-0_20_3" tag will 
have the text "$Name$" (or any previous expansion of that text) replaced 
with the text "$Name: fop-0_20_3 $" when checked out.  This is 
reasonable because only that version of that file is associated with 
that tag.  On the other hand, files checked out using "-r 
fop-0_20_3-maintain" will have "$Name" (or any previous expansion of the 
text) set to "$Name:  $", because the branch tag may be applied to any 
version of the file existing in the branch.

There are, of course, implications in this for CVS-derived version 
strings.  The only time that the $Name$ string will be visible is in a 
release.  All other versions, including ongoing development versions, 
will see "$Name:  $"  I don't consider this disadvantage to outweigh the 
advantages of a guaranteed association between the CVS tree and the 
version reported by formal releases.  To maximise these advantages, 
every class source file in the tree should have

public static final String header = "$Header$", tag = "$Name$";

Build information is then available in binary distributions through the 
 RCS ident command.  E.g.

java 16:20$ ident Junk2.class
Junk2.class:
 $Header: /home/pbw/src/java/RCS/Junk2.java,v 1.1 2002-04-25 
16:19:05+10 pbw Exp pbw $
 $Name:  $

In the case of formal releases, the occurrence of an empty $Name$ 
keyword indicates a failure of the build process.  The $Header$ keyword 
can then give some clues as to why.

***WARNING*** Jars and class files checked into CVS must have their '-k' 
flag defaulted to 'o' - original value at checkin - to prevent 
corruption of binary files.  I don't know whether this is critical for 
class files, but I would not treat them as binary files.

To construct a release, the set of committed files in the tree from 
which the release is being prepared will have to be tagged, as they are 
now, by cvs tag, or possibly by cvs rtag.  This set of files will then 
have to be extracted with 'cvs checkout -r TAG' in order to ensure that 
the $Name$ keyword is expanded with the release tag.  Release builds 
would be prepared from this tree.

A side-effect of this will be that the source tree of the release will 
have a sticky tag; the release tag.  If this tree were left in place, 
and maintenance attempted within it, any attempt to commit changes would 
fail because of the sticky tag, because it refers only to one particular 
version of each file.  E.g., if a release of FOP_Release_0-20-4Final 
were made, and some fixes applied in the same tree, a commit would fail with

cvs commit: sticky tag `FOP_Release_0-20-4Final' for file `whatever' is 
not a branch
cvs [commit aborted]: correct above errors first!

To properly maintain this release, a branch tag should be created from 
the tree.

$ rtag  -b  -r  FOP_Release_0-20-4Final   FOP_0-20-4_maint   xml-fop

then, at the top of the release tree,

$ cvs checkout  -r FOP_0-20-4_maint

To the best of my knowledge, the new branch tag will become sticky, 
overwriting the previous release tag.

What about the empty $Name$ keyword in the development branch, i.e. the 
trunk?  It doesn't really matter for development.  Once the process is 
tested and trusted, the absence of a $Name$ keyword is nto crucial.  In 
any case, a special moving tag could be used to test on the trunk. 
 Assign, say, FOP_0-10-0_Dummy as a testing tag.  Then, to test the 
trunk with a valid $Name$ keyword,

$ cvs -d root-value rtag -F -r HEAD FOP_0-10-0_Dummy xml-fop

This assigns the release tag FOP_0-10-0_Dummy to the current HEAD 
versions.  The -F flag will move the tag if it exists, e.g., from a 
previous test.  Note that the $Name$ keyword will not be set in

Re: Tags in CVS

[Peter B. West]

Well, Peter, I have another suggestion.  To allow for a few more options 
in the pretty-printing of the version, extend the convention a little. 
 The proposal is that digit-digit stand for digit.digit.  Let 
digit--digit stand for digit-digit.  The proposal is that underscore 
always stands for space.  Restrict that by letting [not underscore]_[not 
underscore] stand for [not underscore]space[not underscore].  All other 
hyphens and underscores (e.g. at the beginning of a tag) to stand unchanged.

In most cases these extensions will be irrelevant, but the do give the 
option to have a version display as, e.g.
"FOP 0.20.3-2 Unstable".  The tag for this would be 
"FOP_0-20-3--2_Unstable", which virtually speaks for itself.

Using perl REs,
Character set: [A-Za-z_-]
Replacements:
   /([0-9])-(?=[0-9])/$1./g
   /([0-9])--(?=[0-9])/$1-/g
   /([^_])_(?=[^_])/$1 /g

Looking at cvs.apache.org:/home/cvs/CVSROOT/val-tags, it is obvious 
there is no standard for tag names, so no-one's nose would be put out of 
joint.  I'll have a tinker with this on a branch.

Incidentally, there is no fop-0_20_3-maintain, or rather, fop-0_20_3 is 
on the fop-0_20_2-maintain branch.

Peter

Peter B. West wrote:

> Fops,
>
> I assume that no general standards apply to symbolic tag names in CVS. 
> Does anyone have any information to the contrary?
>
> If not, I propose that we adopt our own standard.  CVS, I have 
> discovered, is more restrictive that RCS in the construction of 
> symbolic names.  It only allows [A-Za-z0-9_-].  That narrows the 
> options for escaping dots.  What I have in mind is the desirability of 
> converting tags into a more readable strings, especially in repect of 
> numbering. There's not a lot that can be done, but if we say that 
> underscore stands for space, and hyphen is itself, except when 
> separating digits, we can construct reasonable tags without too much 
> awkwardness.  So FOP_Release_0-20-4RC1 would display (from Version, 
> e.g.) as "FOP Release 0.20.4RC1" and FOP_Nitro-0-20-4-Experimental as 
> "FOP Nitro-0.20.4-Experimental".
>
> Any other suggestions?




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

Re: Regenerating design docs

[Peter B. West]

Keiron,

Ok, I forgot.  Again.

Peter

Keiron Liddle wrote:

> this should answer you:
> http://marc.theaimsgroup.com/?l=fop-dev&m=101644341904851&w=2
>
> the html is committed into cvs, then a cvs up is done on the live 
> website cvs (xml.apache.org).
>



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

Re: inital background-image patch

[Peter B. West]

Arved,


4.9.6 Layering and Conflict of Marks

has

"If A and B are areas with the same stacking layer, the backgrounds of A 
and B come beneath all other marks generated by A and B. Further, if A 
is an ancestor of B (still with the same stacking layer), then the 
background of A is beneath all the areas of B, and all the areas of B 
are beneath the intrinsic areas (and border) of A.

"If A and B have the same stacking layer and neither is an ancestor of 
the other, then it is an error if either their backgrounds conflict or 
if a non-background mark of A conflicts with a non-background mark of B. 
An implementation may recover by proceeding as if the marks from the 
first area in the pre-order traversal order are beneath those of the 
other area."


Reading the rest of the section, I would assume that in the absence of 
any specific z-index values, all of the descendants of the region share 
the region's z-index.  In that case the first of the paragraphs above 
would seem to hold, which would put the region backgound at the bottom. 
 Fortunately the regions generate no intrinsic marks.  In the case of 
conflicts (second paragraph) the marks generated at the region would 
still be on the bottom.

Peter

Arved Sandstrom wrote:

>The only thing that may cause a problem with this interpretation, if outer
>regions are being used, is in rendering conflict of marks. You cannot
>specify z-index on regions so this only works if you can guarantee that
>region-body gets rendered first, and I don't know if that is a spec
>requirement.
>
>  
>



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

Aids to distributed design

[Peter B. West]

Fops,

I have been thinking for some time now about the difficulty of doing 
distributed design; i.e., co-ordinating design thinking in OS projects 
with widely separated designers, and others who may like to make 
suggestions.  For a start, I think that intermittent email communication 
is inadequate to the task.  Compare the situation with designers sitting 
in the same room, able to walk over to talk to one another about design 
ideas, gather round a white board, and generally kick ideas around in 
real time.

While I am not suggesting that anything much is likely to change in the 
current situation, I think that one of the lessons here is the 
importance of chat.  This is particularly difficult with wide 
geographical distribution, but I have done it on occasions with a group 
spread from California through New York and London to Tokyo and 
Brisbane.  The major hurdle is finding any times when everyone can be 
available.  Even when not everyone could be there, logs of the 
conversation could be very valuable.

The other critical component is drawings.  If I had the choice of 
unlimited text or drawings with minimal annotations for communicating 
design ideas, I would take the drawings every time.  I'm not talking 
here about formal techniques like UML, which are design documentation 
tools, but the informal scribblings which are universal when programmers 
- sorry, engineers - get together to talk design, and which are the 
basic tool of all of my design thinking.

What would be good is to combine the two.  I.e., to chat on the one 
hand, and on the other to be able to use a vector drawing tool with a 
distributed canvas, which others could annotate or modify in real time, 
during the chat session.  Does anything like that exist?

Peter


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

Regenerating design docs

[Peter B. West]

Fops,

Karen asked some time ago about regenerating the html docs on the web 
site.  I didn't notice an answer to that one.  How is it done?

Peter


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

Re: build failure with J2SDK1.4

[Peter B. West]

Keiron Liddle wrote:

> On 2002.04.19 11:55 Cyril Rognon wrote:
>
>> Hi Fopers
>>
>> I have checked out the 0.20.3 with a -r fop-0_20_3 version tag (think 
>> that's the right thing to do to get the 0.20.3 release)
>>
>> Then I have uncommented the new method in 
>> src/org/apache/fop/svg/PDFGraphics2D.java
>>
>>
>> when I try to build FOP, I get an error after 14 seconds. If anyone 
>> has some ideas, I take it !
>>
>> The classpath set for the build :
>>
>> Fop Build System
>> 
>> Building with classpath 
>> 
>C:\bin\jsdk1.4.0\lib\tools.jar;C:\bin\jsdk1.4.0\lib\classes.zip;lib\ant.jar;lib\ant-1.3-optional.jar;lib\batik.jar;lib\buildtools.jar;lib\xerces-1.2.3.jar;lib\xalan-2.0.0.jar;lib\xalanj1compat.jar;lib\bsf.jar;lib\jimi-1.0.jar;lib\logkit-1.0.jar;lib\avalon-framework-4.0.jar
> 
>>
>>
>> Here is the trace of the build failure :
>>
>> 
>> [style] Transforming into 
>> E:\cvs\fop\maintain\xml-fop\build\src\org\apache\fop\render\pdf
>> [style] Loading stylesheet 
>> E:\cvs\fop\maintain\xml-fop\.\build\src\codegen\code-point-mapping.xsl
>> [style] Processing 
>> E:\cvs\fop\maintain\xml-fop\build\src\codegen\encodings.xml to 
>> 
>E:\cvs\fop\maintain\xml-fop\build\src\org\apache\fop\render\pdf\CodePointMapping.java 
>>
>> [style] Failed to process 
>> E:\cvs\fop\maintain\xml-fop\build\src\codegen\encodings.xml
>>
>> BUILD FAILED
>>
>> E:\cvs\fop\maintain\xml-fop\build.xml:472: 
>> javax.xml.transform.TransformerException: 
>> org.xml.sax.SAXParseException: File 
>> 
>"file:///E:/cvs/fop/maintain/xml-fop/E:/cvs/fop/maintain/xml-fop/build/src/codegen/encodings.xml"
> 
>> not found.
>> --- Nested Exception --- 
>

Cyril, Keiron,

Could there be some bizarre bug which is converting a filespec like
E:\cvs\fop\maintain\xml-fop\.\build\src\codegen\code-point-mapping.xsl
into
E:\cvs\fop\maintain\xml-fop\E:\cvs\fop\maintain\xml-fop\build\src\codegen\code-point-mapping.xsl
 

in certain circumstances?

Peter


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

Re: cvs access

[Peter B. West]

Arved Sandstrom wrote:

>Not at all, to the first. I've been using DHCP on Windows and Linux for
>quite a while and CVS over SSH has not involved any aggro with respect to
>.rhosts. Once you've got your public/private key pair created, and you've
>uploaded your public key (and placed it into 'authorized_keys' on the CVS
>server), you are set, assuming that your CVSROOT and CVS_RSH are also
>specified.
>
Thanks Arved.

>To the second, yes, in theory, if I am not mistaken. I believe I have done
>this before. It may be as simple as just modifying the Root files in your
>CVS directories. You can only try - it's not like it's going to destroy
>anything.
>  
>
I'll edit Root and try an update.  I wasn't sure whether CVS was 
stateless as far as checkouts were concerned.

Peter


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

cvs access

[Peter B. West]

Committers,

Ok, I have my account.  Now, how do I use it?  I'm assuming that I set 
CVS_RSH=ssh, and use
-d :ext:[EMAIL PROTECTED]:/home/cvspublic
to specify CVSROOT.  That would mean setting .rhosts, wouldn't it? 
 Which is painful because I get a dynamic IP address.

Once I get that worked out, so I have to do full checkouts again, or is 
it possible to hack the CVS entries in my existing anonymous checkout trees?

Peter


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

Re: Keeps and space specifiers

[Peter B. West]

Keiron,

That would be just a matter of associating a value with the keep.  The 
main thing about the approach I outlined is to provide a structure which 
allows keeps (and stacking constraints) to be expressed more readily.

Incidentally, speaking of min/opt/max values, my feeling is that, in a 
look-ahead model, the initial layout should use optimum values only. 
 Then, only if some layout infelicity or contradiction occurs, the 
layout manager, wherever that sits in the process hierarchy, will start 
probing the galleys for possible layouts in the minimum ior maximum 
directions.  Which to try first will probably be heuristically 
determined, based on the type of layout errors which can occur.  One of 
the variables here will be the "strength" of keeps, but, as far as I can 
tell, the weakest keep will only be discarded after the options implicit 
in min/opt/max have been exhausted.  I haven't given any thought to any 
of this, though.

Peter

Keiron Liddle wrote:

>
> Does this take into account the keep values that have the range: 0..9, 
> always. It is not possible to simply say that a given group of keeps 
> should stay together, you need to find the lowest keep value closest 
> to the optimum spacing position and within minimum.
>
>



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

Keeps and space specifiers

[Peter B. West]

Soothed Foperators,

I have been looking for a while, like everybody else, at keeps.  I was 
looking for a way to unify the processing of keeps and breaks at the 
layout level.  Breaks are easy enough; just create column-break and 
page-break pseudo-area and insert into the galley as a sibling of the 
affected object's area subtree.  Once that's done, look-ahead and 
re-layout operate on the same stream of galley objects.  However, keeps 
didn't fit.

It occurred to me that, conceptually, the keeps can all be expressed as 
a new keep-together pseudo-area.  The keep-together property itself is 
expressed during layout by wrapping all of the generated areas in a 
keep-together area.  Keep-with-previous on formatting object A becomes a 
keep-together area spanning the first non-blank normal area leaf node, 
L, generated by A or its offspring, and the last non-blank normal area 
leaf node preceding L in the area tree.  Likewise, keep-with-next on 
formatting object A becomes a keep-together area spanning the last 
non-blank normal area leaf node, L, generated by A or its offspring, and 
the first non-blank normal area leaf node following L in the area tree.

The obvious problem with this arrangement is that the keep-together area 
violate the hierarachical arrangement of the layout tree.  They form a 
concurrent structure focussed on the leaf nodes.  This seems to be the 
essential problem of handling keep-with-(previous/next); that it cuts 
across the naturally tree-structured flow of processing.  Such problems 
are endemic in page layout.

In any case, it seems that the relationships between areas that are of 
interest in keep processing need some form of direct expression, 
parallel to the layout tree itself.  I have yet to examine inline 
relationships or the problem of changes in block-progression-direction, 
but just looking at the simple block stacking cases, you get a diagram 
like the attached PNG.  In order to track the relationships through the 
tree, I think you need four sets of links.  The basic links are:

Leading edge to leading edge of first normal child.
Trailing edge to leading edge of next normal sibling.
Trailing edge to trailing edge of parent

Superimposed on the basic links are bridging links which span adjacent 
sets of links.  These spanning links are the tree violators, and give 
direct access to the areas which are of interest in keep processing. 
 They could be implemented as double-linked lists, either within the 
layout tree nodes or as separate structures.  Gaps in the spanning links 
are joined by simply reproducing the single links, as in the diagram. 
 The whole layout tree for a page is effectively threaded in order of 
interest, as far as keeps are concerned.

The bonus of this structure is that it looks like a superset of the 
stacking constraints.  It gives direct access to all sets of adjacent 
edges and sets of edges whose space specifiers need to be resolved. 
 Fences can be easily enough detected during the process of space 
resolution.

I will be looking at what happens with changes of 
block-progression-direction and the related structures for inline keeps. 
 How does this gel with what other people are doing with keeps?

Peter



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

Re: AW: Multithreading FOP ?

[Peter B. West]

Joerg,

Thanks, it does answer my questions, and raises a few others.  I'm 
heartened by this, because what you have described is the inappropriate 
use of global data in a multi-threaded context.  I'm interested because 
I like statics.  They are smaller and faster; what's not to like? 
 Before continuing with them, though, I need to make sure that I 
understand the problems.

The scenario you describe is a doomed attempt to globalise local data. 
 However, there are times when some initialization of truly global data 
is required, yet it cannot be accomplished with static{} blocks.  What's 
needed is a one-time initialization method.  This can be synchronized. 
 Protect the initialization method or some initialization object, and 
set a flag within the method to declare that the job is done.  Test this 
on entry, after synchronization.  Because none of the processes which 
require the data will attempt access until after init, access itself 
does not need to be synchronized.  (I'm assuming here that all statics 
are global relative to the JVM.)

It seems to me, of what I have heard so far, that there is no problem 
with statics _per se_.  If they are used with an awareness of the 
possibility of multi-threading, they should present no special 
difficulties.  I have heard it said, though, that statics are forbidden 
in EJB environments.  Is this true?  If so, what are the special 
constraints that apply to EJBs?

Regarding configuration in FOP, it is interesting to note that there are 
two different config hierarchies depending on whether the environment is 
uniform, as, e.g., in a single thread, or diverse, as in the example 
Arnd offered.  (That is, a separate process constructs stylesheet 
information and other variables into an instance-specific storage 
location, and invokes a fop thread with a reference to that location.)

In the first case, the config hierarchy is:

system config
user config
command line

despite the fact that the user config file may be specified on the 
command line.  Other data from the command line will override 
assignments in the user config (else why specify them?)

In the second scenario, the most instance-specific data is in the user 
config file (if that is being used to pass the instance data) or in some 
other instance-specific config source.  So the hierarchy looks like:

system config
command line
user config

or

system config
user config
command line
instance config

I like the second idea better.

Not knowing a great deal about JVMs and class loaders, I'm curious to 
know how dynamic data can be introduced into threads started within a 
pre-existing JVM.  One solution of Arnd's problem would seem to be to 
control the process of setting up the FOP thread configuration 
subdirectories from within the JVM, and allow for new FOP objects to be 
initialised with this information.  That is not a general solution ot 
the problem though.  How is it usually done?

Peter


J.Pietschmann wrote:

> The problem is multiple threads accessing static class data,
> which is really global.
> Well, the standard scenario is: There are multiple threads
> sleeping while waiting for requests. One thread wakes up,
> sets the FOP baseDir, creates a Driver instqance and starts
> rendering. Just before the thread is about to resolve an URI
> for an external graphic, it is suspended and another thread
> gets a chance to run, it reads its request, sets the global
> baseDir to soemthing else, and is itself suspended in favour
> for the first thread, which reads the now changed value for
> baseDir from the configuration, and explodes.
>
> It doesn't help to make the Driver methods synchronized,
> because there are two instances of the driver object :-(
> you would have to lock the global configuration data so
> that the second thread would have to wait until the first
> finishes processing. Of course, this nullifies the advantages
> of using multithreading, especially on MP machines.
>
> I like the approach JAXP did for transformers. You have
> a factory where you can set default stuff so that you
> don't have to do this every time an individual processor
> is created, and you can override settings on the individual
> instances. The individual processor instances never access
> global data after creation.
>
> Does this answer your question(s)?




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

Re: [Vote] New committer: Jeremias Maerki

[Peter B. West]

For what it's worth, I give moral support to this nomination.

Peter

Christian Geisert wrote:

> I would like to propose Jeremias Maerki as a new committert for Fop.
>
> Jeremias has already contibuted the PS Renderer and quite a few 
> bugfixes/patches, helped to improve the documentation and is very
> helpful on the mailing lists.
>



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

Re: AW: Multithreading FOP ?

[Peter B. West]

Folks,

Please indulge my ignorance again.  May I assume that it is not possible 
to run two main()s in the same VM?

 From this discussion so far I have gained much more insight into the 
nervousness about statics.  Is the problem that servers want to execute 
multiple instances of classes within the one VM?  Are there other problems?

Peter


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

Re: AW: Multithreading FOP ?

[Peter B. West]

Please excuse my ignorance of these issues, but what mechanisms would 
folks expect to use to set per-invocation configurations for FOP?

Peter

Chaumette, Patrick wrote:

>Thanks for the infos,
>
>also got this from Arnd
>
>
>--
>One problem you may run across is that configuration in FOP is help in
>global objects. 
>Besides not being thread-safe you will not be able to run multiple FOP
>threads with different 
>configuration settings. If you want to investigate this, look for the class
>Options. 
>
>I ran across this problem during invoice printing on multiprocessor machines
>and finally 
>decided to start a separate VM for each FOP instance. 
>
>Hope this helps, 
>
>Arnd Beissner 
>



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

Re: [Vote] New committers: Peter West, Joerg Pietschmann?

[Peter B. West]

Keiron,

I await the result of the vote, but I am grateful for the nomination, 
and would be happy to accept.

Let me say that anyone who has monitored the Mulberry XSL list over the 
last 18 months will be aware of just how prolific, knowledgeable and 
innovative Joerg is in this area.

Peter

Keiron Liddle wrote:

>
> I propose that we offer Peter West and Joerg Pietschmann to become
> committers.
>
> Peter has of course shown lots of commitment of the last year+.
> Joerg is helping a lot with user questions FAQ etc.
>
> If they accept then I am sure it will help with the valuable work they 
> are contributing to FOP.
>
> Needless to say I am +1 for both.




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

Re: Some comments on the build system

[Peter B. West]

Keiron,

Here's how the RCS works.

$ rlog names

RCS file: names,v
Working file: names
head: 1.2
branch:
locks: strict
access list:
symbolic names:
Rel_1: 1.1.1.2
RC1: 1.2.1.3
Rel: 1.1.1
Dev: 1.2.1
Base: 1.1
keyword substitution: kv
total revisions: 7; selected revisions: 7
description:
$Name$ test

revision 1.2
date: 2002-04-10 08:10:16+10;  author: pbw;  state: Exp;  lines: +3 -3
branches:  1.2.1;
*** empty log message ***

revision 1.1
date: 2002-04-10 08:08:33+10;  author: pbw;  state: Exp;
branches:  1.1.1;
Initial revision

revision 1.1.1.2
date: 2002-04-10 08:36:59+10;  author: pbw;  state: Exp;  lines: +2 -2
Release 1

revision 1.1.1.1
date: 2002-04-10 08:28:33+10;  author: pbw;  state: Exp;  lines: +3 -3
Release branch

revision 1.2.1.3
date: 2002-04-10 08:26:22+10;  author: pbw;  state: Exp;  lines: +3 -3
Release candidate

revision 1.2.1.2
date: 2002-04-10 08:13:13+10;  author: pbw;  state: Exp;  lines: +2 -2
Churning...

revision 1.2.1.1
date: 2002-04-10 08:11:44+10;  author: pbw;  state: Exp;  lines: +3 -3
Development branch
=


Note the names "Rel" and "Dev" refer to branches; 1.1.1 and 1.2.1 
respectively.

So:

$ co -rRel names
names,v  -->  names
revision 1.1.1.2
done
$ cat names
$Id: names,v 1.1.1.2 2002-04-10 08:36:59+10 pbw Exp $
$Name:  $
1.1.1.2

Note the empty Name keyword.  co -rDev gives a similar result.  But:

$ co -rRel_1 names
names,v  -->  names
revision 1.1.1.2
done
$ cat names
$Id: names,v 1.1.1.2 2002-04-10 08:36:59+10 pbw Exp $
$Name: Rel_1 $
1.1.1.2

fills in the blanks.

However:
$ co -r1.1.1.2 names
names,v  -->  names
revision 1.1.1.2
done
$ cat names
$Id: names,v 1.1.1.2 2002-04-10 08:36:59+10 pbw Exp $
$Name:  $
1.1.1.2

I.e., unless the actual revision you check out has a symbolic name AND 
you check it out using that name, the $Name$ keyword will be empty.

Peter


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

Re: Some comments on the build system

[Peter B. West]

Arved,

Obviously, I share many of your attitudes to properties, but I differ in 
one respect.  I think of properties not as rich, but as impoverished. 
 To me, they are just associations of names with values.  The richness 
lies in their treatment in the process of layout, where all of those 
constraints and interactions will have to be accommodated and resolved 
in the application of properties to FOs and areas.  Interactions, e.g., 
are inherently "outside" any individual property.  Constraints, I have 
to admit, are generally property-centric, even where they involve 
testing the value of other properties.  This view underlies my attempt 
to reduce property handling to a set of arrays.  I still have an 
individual (though nested) class for each property, from which 
commonalities are extracted, while special cases are handled by methods 
peculiar to the class.

Your concerns (and mine) about the association of build.xml release 
number and the tag would be resolved by making them identical, or at 
least deriving the first from the second.  If my understanding of the 
relationship between RCS and CVS is correct, we can do this.

Peter

Arved Sandstrom wrote:

>Hi, Peter
>
>I personally agree that the properties don't need the XML+XSLT approach.
>Even if one leaves aside the aural properties there are over 250 properties,
>and on close inspection the commonalities are limited. I believe the largest
>group size of properties that are identical is 4. Many properties have extra
>constraints (they interoperate with other properties, for example), they
>accept different combinations of input generic types, percentages have
>meaning only in the context of the property, and so on and so forth.
>
>One could come up with a super-sophisticated XML+XSLT system to embody all
>this, but why bother?
>
>I'm not going to bad-mouth the current system that FOP has. I acquiesced at
>least implicitly in the choice to at least continue with it, at an early
>stage. But I now believe that the right place for a lot of logic related to
>properties is actually in the properties. I think an XML+XSLT approach
>pushes a lot of that out into places where it ought not to be.
>
>Most of the common handling has actually little to do with the properties
>per se - it has to do with expressions and datatypes. This is not the same
>thing. An XSL property is not a datatype, IMO, and shouldn't be regarded
>that way.
>
>I don't think it's a pressing issue unless someone then immediately proposes
>and moves forward with work to make the properties rich, interesting things.
>It's not really an IDE issue - there are IDEs that handle the current FOP
>setup just fine.
>
>I also agree that ease of making changes to properties is not a compelling
>argument for XML files, nor for using XSLT to generate the code. The
>properties are simply not that similar. So you may as well work on Java
>properties files directly. And since properties _are_ what make XSL, if
>there are significant changes in properties in the spec then the disruption
>is going to be widespread.
>
>I agree with Keiron's observations regarding the other point, about
>versioning. Our numbers are release numbers (major, minor, patch, plus stage
>info, as he puts it), and these require human decision-making. You can't
>automate release numbers sensibly.
>
>Anything else Ant supports (timestamping, token filtering, build number
>incrementing) makes a lot of sense in the right contexts, mostly in the
>sense of configuration management and builds.
>
>I'd like to see a stronger link between the release number in the build.xml
>and the presence of a matching tag in the CVS, myself. I've been personally
>guilty of forgetting to tag the CVS when buildng a distro and it's because
>there was no mechanism to jog my memory. I don't think the tagging itself
>should be automated but some aspect of the source code retrieval prior to
>building a dist* target should be dependent on the presence of a matching
>tag. Let's face it, right now we have no configuration management at all -
>maybe this isn't much better but at least it's something.
>



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

Re: Some comments on the build system

[Peter B. West]

Keiron,

As I suspected, $Name$ is the tag used to check out the file.  In my 
maint checkout, I have a sticky CVS/Tag specifying "fop-0_20_2-maintain" 
(symbolic names cannot contain dot, because "a  revision  is  com­posed  
of  one  or  more numeric or symbolic fields separated by periods"  - 
`man co').  Whenever I update, I am going to get that tag, and any 
$Name$ fields will contain that text.  If the original conf/config.xml 
contains

version
$Name$

I will actually see (given the default -kv flag to CVS)

version
$Name: fop-0_20_2-maintain $

when I checkout or update.  As I can't commit, I can't test this.  Does 
it work that way?  If so, the basis for providing the version string in 
the code is already in place.

If that's unbearably ugly, add some code to Version.java to massage it. 
 Symbolic names can contain any character except [0-9$@.;:], so there's 
plenty of room for establishing a conventional character to represent a 
space in the transformed output.  E.g. FOP@0_20_2-maintain.  I would be 
inclined to leave the underscores; I would be inclined to leave 
FOP-0_20_2-maintain untouched, just stripping off the keyword noise.

$State$ is also available, but seems to require a cvs admin -s.

What about HEAD?  Just set a sticky tag of, say, "FOP-1_0dev" for 
commits, and notify that development checkouts must use this tag.  If 
somone forgets when checking out, I don't think it's critical for 
development, as long as the commits use the tag.  Releases will be 
frozen with the appropriate release tag, e.g., FOP-0_20_2-RC3, as I 
assume is currently done using rtag.

Peter

Keiron Liddle wrote:

>
> This page has the cvs keywords:
> http://www.loria.fr/~molli/cvs/doc/cvs_12.html
>
> None of them seem to be useable for the version of a product.
> You still need to change something to make this update anyway.
>
> On 2002.04.05 00:44 Peter B. West wrote:
>
>> Keiron,
>>
>> I don't know the nuts and bolts of CVS, but I always assumed that 
>> tags were somehow related to the RCS symbolic name, accessible via 
>> $Name$. $Name$ has some peculiarities due to the fact that there is 
>> not a unique name attached to the current version; I think it is set 
>> in the output files from the symbolic name under which the file is 
>> retrieved. I don't know, off hand, what the deault behaviour is.  I 
>> can check the RCS characteristics here.  Do you want to install 
>> $Name$ in one of the CVS files and see what it looks like when 
>> retrieved?
>>



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

Re: Some comments on the build system

[Peter B. West]

Keiron,

I don't know the nuts and bolts of CVS, but I always assumed that tags 
were somehow related to the RCS symbolic name, accessible via $Name$. 
 $Name$ has some peculiarities due to the fact that there is not a 
unique name attached to the current version; I think it is set in the 
output files from the symbolic name under which the file is retrieved. 
 I don't know, off hand, what the deault behaviour is.  I can check the 
RCS characteristics here.  Do you want to install $Name$ in one of the 
CVS files and see what it looks like when retrieved?

Peter

Keiron Liddle wrote:

> On 2002.04.03 18:23 Peter B. West wrote:
>
>> There are a couple of other things which encourage the separation of 
>> source and build.source trees.  They involve the use of copy 
>> filtering in ant.  Version information is, I think, supplied by ant 
>> via the build.xml file.  This vile and disgusting habit, which ant 
>> seems to encourage, should be stamped out at once.  Version 
>> information comes from the version control system in use at the time, 
>> not from hand-hacking on build.xml.  A few changes to Version.java to 
>> massage the output of the RCS macros are all that is needed.  If that 
>> massaging is required during the build itself, an ant task should be 
>> able to do it.
>
>
> I don't quite see how you could use RCS to set the version. The 
> information will only update if something is checked in, what will be 
> changed in the file to check it in? Do you really want the versions to 
> count up 1.[0..n], how do you specify bug, minor and major releases, 
> what about stages ie. dev, alpha, beta, final.
>



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