RE: Development Environment suggestions ?
-Original Message- From: John Austin [mailto:[EMAIL PROTECTED] Sent: November 20, 2003 12:37 PM To: [EMAIL PROTECTED] Subject: Development Environment suggestions ? So far I have been playing around like the Neanderthal* that I am. I use Sun Java 1.4.x with xterm, vi, emacs and occasionally Jedit when I feel modern urges. Peter has mentioned Eclipse and I have used VisualAge for Java, and either NetBeans or the Sun form thereof. If you have a few bucks, you can't beat IntelliJ IDEA. I have used VisualAge and NetBeans, and also JEdit, vi and emacs, but IntelliJ has them all beat hands down. Is there a path to enlightenment (excuse the trollish tone) therein ? Given that FOP can be installed and started in TBI (The Bash IDE), are there other graphical IDE's with a reasonable learning curve ? IntelliJ is fairly easy to pick up. I have both Win98 and RH9 available to me. The RH box has more resources in addition to having the usual Linux advantages. As another poster mentioned, upgrade from Win98. Win98 has limited GDI resources (that is, the amount of memory for actual windows, visible or invisible), so is a PITA for serious development. * Is that term Politically Correct ? Would it be offensive to Europeans ? I myself am descended from Celts and probably some Angles, Jutes and Saxons. Dunno about Picts. As I understand it, Neanderthals were as smart as us Cro-Magnons. :-) AHS
RE: Place committers on inactive list?
-Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: September 2, 2003 2:49 AM To: [EMAIL PROTECTED] Subject: Re: Place committers on inactive list? Le Mardi, 2 sep 2003, à 03:33 Europe/Zurich, Glen Mazza a écrit : ...Perhaps Karen, Arved and Bertrand should be added to the inactive list... No problem for me, I'd actually feel better being listed as inactive! That would be realistic. I have no intentions of permanently leaving the project, but I have been inactive for quite some time. I am just too busy in other pursuits at the moment. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Nomination of Glen Mazza as committer
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: June 16, 2003 5:46 PM To: [EMAIL PROTECTED] Subject: Re: Nomination of Glen Mazza as committer Victor Mote wrote: Being the greenest committer, I had hoped to defer this nomination to a more senior developer. However, I think it is appropriate to nominate Glen Mazza for committer status. He is knowledgeable and thoughtful, and I think it is in the interest of the project to turn him loose so that he can keep working without having to wait on us. +1 And also +1. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Information on who's leading FOP
Hi, Gaurav To add to Jeremias' reply, which is accurate, might I add that there are in fact leaders when it comes to ASF projects? Jeremias is one himself. To be less vague, let me expand by saying that there are committers who are interested in the codebase only, and then there are committers who are interested in more - documentation, planning, the community, etc. The former category, just as the non-committer developers, is not to be denigrated, but you can defintely identify committers who take an interest in the big picture as leaders. Arved Sandstrom -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: March 11, 2003 6:24 PM To: [EMAIL PROTECTED] Subject: Re: Information on who's leading FOP Projects at Apache don't work this way. No boss and underlings. The list of people you found are most probably the committers. They run the project. Here's some more information: http://xml.apache.org/whoweare.html http://incubator.apache.org/drafts/theapacheway.html I hope that helps. If you need more information just call for help. On 11.03.2003 23:13:30 Gaurav Pal wrote: I'm working on a project that will be using FOP as a report generator. While trying to sell the idea to the senior management, I was asked to find out who's leading this effort at Apache. I searched the FOP web site and also the mailing list archives but didnt find anything. There are a number of developers whose names I got from the mailing lists but no information on who is the lead. I'd appreciate it if someone could give me this information or point me to where I could find it. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
-Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: February 25, 2003 9:16 PM To: [EMAIL PROTECTED] Subject: Re: markers in redesign Looking at it again, I disagree. The containing page is the page containing the first area generated or returned by the children of the retrieved fo:marker. That is, the page on which the fo:retrieve-marker occurs in the static-content. This will only vary if the retrieval forces a re-layout. How do you jump from the first sentance to the second one. The containing page refers to the page where the marker is first formatted not where the retrieve-marker occurs. That's now my opinion also, after my re-read. I made the other assumption based on the obfuscated language. I vote for a clarification and a re-write, the containing page is defined by the retrieved marker, the marker to retrieve is defined by the containing page. I think we can all agree on asking for a rewrite. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Hi, Keiron I interpret 6.11.4 as follows. Number one, the names have to match - marker-class-name and retrieve-class-name. This is straightforward. It defines qualifying areas. Number two, qualifying areas are excluded if they follow the page being formatted, regardless of retrieve-boundary. So retrieve-boundary essentially defines the backward limits. Finally, retrieve-boundary also restricts qualifying areas in the backward direction: page says that if it's not on the currently being-formatted page, it isn't up for consideration. For last-starting-within-page, is-first is clear enough I think. An FO is generating and returning areas on the containing page, and the first one is...well, the first one. :-) So it is the optimal candidate if its parent FO has qualifying markers. With reference to your [2], return to the def'n of qualifying area: name-matching, period. I assume last in this context means last geometrically, as opposed to some other last. Eg, immediately preceding as one normally reads a document. I think whoever wrote this portion (markers) made the spec too abstruse. I finally just broke my rule of adhering to the law, and considered the use cases, and decided what made sense. :-) Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: February 23, 2003 6:49 PM To: [EMAIL PROTECTED] Subject: Re: markers in redesign Hi all, Is it correct that it should look for markers on the current page and if page boundary is current page then stop there. If boundary is page-sequence then keep going backwards on each page until a marker is found or reaches the start of the page-sequence and similarly for the document boundary. I'm trying to work out exactly how the markers should work. For the first starting within page and last ending I am fine with. First including carry-over seems okay. Last starting within page is a bit confusing. A statement [1] in the spec suggests that it shouldn't really find the last starting in the page but rather find the closest node to the root in the area tree that is the last starting area. Another statement [2] seems confusing but maybe this is if it is searching previous pages. So if this was in a page then block a would be the last starting in the page. -start-- ... block id=a block id=b /block ---pos1- block id=c /block /block end--- But if there is a column break in pos1 the last starting in page will become block c as block a is not starting in that part of the area tree. If this is the case then there are two possible cases when starting an area: isfirst and other. When finishing an area there are: islast, (had) isfirst and both. This will supply enough information to add only the needed markers to the area tree. These markers can then be kept for later retrieval. [1] Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. [2] If there is no such area, then the last qualifying area in the containing page is better than any other area. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 6:53 AM To: [EMAIL PROTECTED] Subject: Re: markers in redesign [ SNIP ] It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. Yes, that's my interpretation. Precisely so. It is tempting to confuse hierarchy for tree. But the language of the spec in regard of markers defines a different hierarchy, one which happens to map closely to the area tree, but is highly filtered. I re-assert that in the case of this particular section of the spec, we can fall back on common sense, although normally I am loath to do so (it may sound funny to hear that, but I am a professional software developer, and I'd rather follow the letter than the spirit. That approach usually assures better code, and better specs). That means to me that in this case we use the use cases in the spec to identify what makes sense. Markers are amenable to this, as opposed to reference-orientation, because the latter is an artificial concept, and several interpretations may apply. That means, to me, first, that we use the naming to identify qualifying areas. Two, we use retrieve-boundary to filter out qualifying areas. I make that distinction, because qualifying areas are defined by the naming alone. Three, we use retrieve-position coupled with area traits (and the traits are easy to establish) to figure out the best qualifier on the _current_ page. The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user preferences based on retrieve-position lose all relevance. In other words, there is an elaborate set of definitions based on the current page, with a hierarchy defined by retrieve-position, but as soon as one establishes that there is no such qualifying area on the current page, than it's just the first qualifying area one can find, moving back in the document. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Comments inline. -Original Message- From: Tony Graham [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 10:26 AM To: [EMAIL PROTECTED] Subject: RE: markers in redesign Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400: Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 6:53 AM To: [EMAIL PROTECTED] Subject: Re: markers in redesign [ SNIP ] It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. Yes, that's my interpretation. Precisely so. It is tempting to confuse hierarchy for tree. But the language of the spec in regard of markers defines a different hierarchy, one which happens to map closely to the area tree, but is highly filtered. It's not just areas. fo:wrapper 'does not generate any areas', but also 'may always have a sequence of zero or more fo:markers as its initial children.' No, you're quite right, Tony, fo:wrapper does not generate areas. But it _returns_ areas, assuming that its children do (there are presumably some pathological cases), and those areas are what markers act on. wrapper is transparent. I may have missed your point on this. ... The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user I wasn't there when the spec was written, but it seems to me that 'currently-formatted page' presupposes making pages on the fly and doesn't quite describe pages that are unbounded in one or both directions (i.e. where there is only ever one page) and also doesn't describe the possible processing model of making all the pages from the fo:flow and then going back and fixing up the static content. OK, you've got me here. :-) I fall into the trap of ignoring media-usage too frequently. So the point is well taken. Regarding the second point, that processing model ignores an error-if-overflow value for overflow; process a thousand pages and then only afterwards find out that you ought to have aborted with a message? Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Comments below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 10:59 PM To: [EMAIL PROTECTED] Subject: Re: markers in redesign Exactly. All definitions regarding retrieve-position exclusively refer to the current page. There is not a single word on what should happen if there is no matching marker on the current page but several on the previous page which are eligible. FOP picks the last, but there is absolutely nothing in the spec which backs this, and I searched thoroughly last weekend. For the current page or containing page I take it to mean like so (assuming doc or page-sequence boundary): If we are on the third page of a document and we want to retrieve a first-starting- within-page then it will look on page 3, if it finds the marker then fine. If not then there is no such area (on the current page) and it should look at page 2. Page 2 is now the containing page and it looks for a marker that is first-starting-within- page on page 2. Then page 1... Admitedly it doesn't actually say that, but I can't interpret the wording otherwise. [ SNIP ] I re-read the spec so exhaustively that my eyes are burning. :-) I think Keiron is right. Boy, it would be cool if they could rewrite that section, though. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Markers in areas
Well, Peter, no, I haven't written something this direct - yet. My trust in their responsiveness is at an ebb; they don't answer much communication, of any nature, quickly, so I doubt that they will answer a more critical email at all. FWIW I consider all of the editors to be way more experienced than me, when it comes to documents, and publishing, and so forth. I don't equate that with expertise in math, or programming, or technical writing. Number one, trained technical writers should write technical docs - a whole bunch of W3C recommendations prove that. _I_ am not very good at writing technical docs; I get windy and abstruse. That's why I don't get paid to write docs. :-) Every XSL-FO implementation has a different treatment of reference-orientation. I keep harping on this, I know. In fact, I think _my_ interpretation is correct, and almost everyone else is wrong. I think that because I read the English in the spec. I know that sounds arrogant, but I have told the editors before that I'll implement according to the letter, not the spirit. If they wish to argue that the language says differently than what I think, that's their prerogative. There is a better procedure for turning out specs. The W3C hasn't twigged. Good companies in the industry already know it. It's invite the customers/clients in, get them to hash things out with the programmers and technical writers, and then let the latter two groups turn out a good document, or a good implementation. Or both. In this case the experts are the customers; we have a confused spec because they thought they were the programmers and writers as well. Arved -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 22, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: Re: Markers in areas Arved Sandstrom wrote: They are not connected concepts, Mark. I originally put in the code for lineage pairs, and also started the implementation for markers. So I can assure you that they are completely unrelated. For what it's worth, subsequent contributors have significantly improved on marker support, so I am only commenting from the viewpoint of my knowledge of the spec. I made a few comments in my reply to Joerg. I have a degree in physics, and most of a Masters in physical oceanography. I see considerable mathematical anarchy in the XSL spec, some degree of mathematical naivete, and lots of confusion. My forte is not logic, based on my background, but even a physics guy can dissect the pseudo-logic in that spec. I think plenty of other people have also separated the wheat from the chaff as far as that document is concerned...I think we are due for a rewrite, with lots of the pretentious math excised, and replaced with plain language. Arved, Hear, hear. Arved, have you told the editors this directly? If not, please do. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Long licence
-Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED] Sent: February 21, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: RE: Long licence On Fri, 21 Feb 2003, Arved Sandstrom wrote: I'd like to find out what lawyer thought a long license is needed with every file. Because I question that finding. Question the board (again) for a black/white answer - or work with licensing for a more interactive reply. Point taken. I get too much email already, so I've been averse to joining more lists. Maybe in this case I should join another. But Bear in mind that the current 'license' is more than just strictly a license; it contains elements of copyright, waiver and an agreement. Understood. Bear in mind that the answer to vague questions like that carry very significant price tags; and are very depended on the exact question; which itself by its very nature is inexact. Yes. It's our business to pose the exact questions. It's the business of the lawyer to supply an answer. FWIW, I am not vilifying lawyers. My older sister is one. :-) I feel like the right questions weren't asked. Also bear in mind that there are very, very few layers who actually have studied open-source licenses in sufficient dept; and that most answers from case-law are about proprietary and protectionist stances; and often very US specific; and may be very dated. Yes, I agree. Also bear in mind that the answer differs from jurisdiction to jurisdiction; and from how litagationous/defensive the side you want to err on is. Well, I differ from our US friends on this. I prefer to be terse and clear, and maintain some trust in people. Finally bear in mind that the board propably does not want to ask expensive questions now with respect to the current license; as the new license is not far off - and the new license has taken into account this desire to include by reference. OK, fair enough. I'll wait to see it. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Long licence
Dirk, you may have seen my post on members, about this. The whole length of license issue. I find it odd that it's OK to suggest tools (IDEs/editors, etc) to hide a license. When the argument presented to the board was presumably that the long license is legally required. I'd like to find out what lawyer thought a long license is needed with every file. Because I question that finding. Arved -Original Message- From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]] Sent: February 21, 2003 8:43 AM To: [EMAIL PROTECTED] Subject: Re: Long licence On Fri, 21 Feb 2003, Jeremias Maerki wrote: software developers. :-) It would be so cool, if IDEs would have the ability to hide a licence at the beginning of a file. I;ve seen some clever pragma's/markers which let emacs do this. DW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Long licence
Jeremias, a deliberate decision was taken to frown on condensed licenses or references. That tell me that there is a legal requirement for the license to be in your face. So to speak. In any case, the board was presented (I assume) with a legal opinion to that effect. Which, although IANAL, I dispute. If it so happens that I am wrong (it's been known; I was last wrong on October 14th, 1995), I am sure that someone will so inform me. But I am checking with some local IP lawyers to see what the deal is. My point being that legally there is no distinction between developers working with OSS, and any other users. And in fact the distinction ought not be made, as many of the same developers _are_ users of the codebase. So it is OK to hide the licensing? I think not. I dislike a long boilerplate license. There are two ways to get rid of it - one is to use technological techniques to ignore it. I don't like that. FOP for example has many hundreds of source files...tack in a screen of legal stuff with each one and note that people with dialup just got presented with some extra download time. Significant extra download time. I intend to clarify this issue on the ASF members list. I have problems with this decision. Arved -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: February 21, 2003 9:19 AM To: [EMAIL PROTECTED] Subject: Re: Long licence Arved, I don't see what's bad about it. The licence stays in every file as necessary, the IDE should just as a service to the developer hide the licence because it's not relevant to normal development tasks. On 21.02.2003 14:01:34 Arved Sandstrom wrote: I find it odd that it's OK to suggest tools (IDEs/editors, etc) to hide a license. When the argument presented to the board was presumably that the long license is legally required. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Markers in areas
They are not connected concepts, Mark. I originally put in the code for lineage pairs, and also started the implementation for markers. So I can assure you that they are completely unrelated. For what it's worth, subsequent contributors have significantly improved on marker support, so I am only commenting from the viewpoint of my knowledge of the spec. I made a few comments in my reply to Joerg. I have a degree in physics, and most of a Masters in physical oceanography. I see considerable mathematical anarchy in the XSL spec, some degree of mathematical naivete, and lots of confusion. My forte is not logic, based on my background, but even a physics guy can dissect the pseudo-logic in that spec. I think plenty of other people have also separated the wheat from the chaff as far as that document is concerned...I think we are due for a rewrite, with lots of the pretentious math excised, and replaced with plain language. Arved -Original Message- From: Mark C. Allman [mailto:[EMAIL PROTECTED]] Sent: February 18, 2003 5:16 PM To: [EMAIL PROTECTED] Subject: RE: Markers in areas ... but markers will continue to work as per the XSLFO spec, correct? We depend on markers for dynamic page headings. -- Mark C. Allman -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 4:09 PM To: [EMAIL PROTECTED] Subject: Re: Markers in areas Arved Sandstrom wrote: Joerg, you can freely get rid of that stuff. Great! Anybody out there bothering to profile the new code? Two objects less created per Area, this should be noticable! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Markers in areas
Joerg, you can freely get rid of that stuff. I originally introduced it when I had more faith in the spec, and thought that the authors knew what they were talking about when it came to to their math. Specifically, the lineage pairs is an abstract concept that I can see no implementation use for. In fact, I can't see any theoretical use for the idea either. Arved -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: February 16, 2003 8:14 PM To: [EMAIL PROTECTED] Subject: Markers in areas Hi, does somebody need the markers attached to an area? I just canned them, as well as another array atteched to areas (lineage pairs). Markers were only used in the XML renderer. They ought to have uses to implement retrieve-positions first-include-carryover and last-ending-within-page, but they didn't get used for this. Objections? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Footnote Problem
-Original Message- From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]] Sent: January 3, 2003 5:53 PM To: [EMAIL PROTECTED] Subject: Footnote Problem Hi all, is the footnote are supposed to span the whole page width even if the body region has columns? If so, adding a footnote would cause reshuffling of content of already filled columns, which in turn might push the FO causing the footnote onto the next page (another candidate for the anomalous layout wiki?). Apart from this, is this case similar enough to rebalancing in case a fo:block span=all is encountered? Yes. There is no provision for columns in the footnote region. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Overconstraint Anomalous documents page in Wiki
Title: JforIntegrationInFop - background and guidelines I looked at the page, Rhett. It looks good as a mission statement. This area interests me a lot too, and I hope to start adding to it. Arved -Original Message-From: Rhett Aultman [mailto:[EMAIL PROTECTED]]Sent: December 26, 2002 2:39 PMTo: [EMAIL PROTECTED]Subject: Overconstraint Anomalous documents page in Wiki Foppers, I've added a page to the Wiki in an attempt to put all of our previous discussion and what documentation I can find regarding overconstraint, anomalous documents, etc. It's located at: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPOverConstraintDesign I'd like to make this part of a general documentation of layout design in general, and hope to be a strong facilitator in its development on the Wiki. I welcome anyone who's had anything to say about overconstraint or other anomalous conditions in the past to start putting their ideas up on the page. With a little work, I think we can start incorporating a design for overconstraint resolution into the HEAD layout managers. I see the rudiments of that system already forming, so I think we've got a good starting point.
RE: Sun XSL Formatter
But it was plausible. :-) -Original Message- From: Patrick Dean Rusk [mailto:[EMAIL PROTECTED]] Sent: December 18, 2002 12:51 PM To: [EMAIL PROTECTED] Subject: RE: Sun XSL Formatter Then I retract the suggestion. Pat -Original Message- From: Tony Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 8:36 AM To: [EMAIL PROTECTED] Subject: RE: Sun XSL Formatter Patrick Dean Rusk wrote at 17 Dec 2002 17:40:11 -0500: Perhaps Tony knows better, but I have a potentially plausible explanation for Sun being secretive about their project: it may not initially have been intended for eventual open source development. In other words, it could be a failed internal project to create a commercial product. No. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
-Original Message- From: Tony Graham [mailto:[EMAIL PROTECTED]] Sent: December 16, 2002 12:23 PM To: [EMAIL PROTECTED] Subject: RE: Sun XSL Formatter Arved Sandstrom wrote at 14 Dec 2002 15:05:05 -0400: No bitterness at all, actually, Peter. It takes a bit of wind out of my sails, sure, since xmlroff is so similar to the project that Eric Bischoff and myself were working on. Tony has certainly been aware of that for quite a long time - I don't understand why the secrecy, myself, seeing as how we are now looking at an OSS donation anyway. Sun policy, not personal policy. I assure you that there are many steps, and many signatures, required when a large corporation makes an open source donation. Purely because it is a large corporation making the donation and not an individual contributor, there is a lot of due diligence to be done. If a project can't pass all the criteria, it won't be made public. Since a project intended for open souce may not make it to open source, it is perhaps better to say nothing until the due diligence is completed (or, in this case, very nearly completed). The alternative -- announcing an intention to make a public source donation -- risks the project not passing the criteria and risks later accusations of vapourware or accusations of lack of commitment to open source when the project can't be made public. That's why I couldn't say anything about the formatter in the lead up to XML 2002: any of a number of people -- not just engineers and engineering managers -- could have vetoed the donation for any of a number of reasons, and I would have just had to withdraw from the conference without another word being said. I actually know that. I was just blowing off steam. :-) I'd be bitter if I were so arrogant as to think of myself as being upstaged. :-) That's not the case. I am quite familiar with the spec, and there are now a number of competing efforts. None of which are quite accurate. So there is room for more competition. Alternatively, I may talk to Tony and Eric and see if we can assist. Part of why it is written in C is so it doesn't compete with FOP for developers. Arved took the wind out of my sails for a while when he announced his SourceForge project, so wind taking runs both ways. I would be pleased if Arved and/or Eric would consider assisting with the project. Frankly, I would be pleased if *anybody* assisted with the project, but Arved and Eric would be a bonus. Eric will have to weigh in himself. I think he is partial to C++. I am partial to C, and said that earlier this year; it was my original intention to go with C. I've been dormant on xslfoproc for a while; work has not permitted much OSS for me at all. I may have time coming up; it would be a pleasure to help out. I also concur that it would be nice to have Eric involved. I see no reason for competition. A single decent open-source C or C++ implementation would be great. Incidentally, my comments about potentially having had to consider the adoption of this project into Apache still stand. It is no reflection on the project, or on you, Tony. It is a personal philosophical stance - yes, company donations have provided the ASF with fine software, but there is a downside. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
-Original Message- From: Peter S. Housel [mailto:[EMAIL PROTECTED]] Sent: December 14, 2002 2:21 PM To: [EMAIL PROTECTED] Subject: Re: Sun XSL Formatter Arved Sandstrom [EMAIL PROTECTED] writes: Well, Java or C or C++ or Haskell, it would have been nice to have a clue. We have an ASF tradition of developing communities...this kind of stuff that Sun and IBM does is getting old. Don't open-source it; sell it. I will argue against its adoption into Apache. Googling for xmlroff yields: http://www.plurb.com/webservices/UBL4.pdf Looks like they want to donate it to Gnome, not Apache. Despite your not wanting to sound bitter, your protest still sounds bitter anyway. -Peter- No bitterness at all, actually, Peter. It takes a bit of wind out of my sails, sure, since xmlroff is so similar to the project that Eric Bischoff and myself were working on. Tony has certainly been aware of that for quite a long time - I don't understand why the secrecy, myself, seeing as how we are now looking at an OSS donation anyway. I'd be bitter if I were so arrogant as to think of myself as being upstaged. :-) That's not the case. I am quite familiar with the spec, and there are now a number of competing efforts. None of which are quite accurate. So there is room for more competition. Alternatively, I may talk to Tony and Eric and see if we can assist. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED]] Sent: December 14, 2002 3:01 PM To: [EMAIL PROTECTED] Subject: RE: Sun XSL Formatter Peter S. Housel wrote: Looks like they want to donate it to Gnome, not Apache. AFAIR, the BSD license is pretty incompatible with the Apache license. One of the reasons that the xmlroff announcement doesn't change my commitment to FOP is that, for my interests anyway, the Apache license is superior. Others are that it is not written in Java, and only runs on Sun-supported operating systems. It almost seems like Java was bypassed because it runs on Microsoft operating systems. There are other deficiencies that I think are probable, but we won't know until we get to play with it. I definitely intend to keep plugging away at FOP. Victor Mote Victor, I intend to continue supporting FOP myself. But can I point out that C is about as portable as it gets? Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED]] Sent: December 14, 2002 3:40 PM To: [EMAIL PROTECTED] Subject: RE: Sun XSL Formatter Arved Sandstrom wrote: But can I point out that C is about as portable as it gets? Maybe someone on this list has time to throw xmlroff source code into Visual Studio let us know how it goes :-) I'll probably do just that. If it was well-written code then it'll compile. There is nothing OS-specific about XSL, barring optimizations. Sorry, I don't mean to be smart. It certainly seems to me that C-portable is an entirely different concept than Java-portable. Sure, in a narrow sense. Binary rather than source. In practical terms C is considerably more portable. Java is basically a Windows and MacOS X VM. Also, I didn't intend to /only/ highlight portability. Java has lots of other advantages over C that are important to this kind of application. I won't recite them here, since everyone on this list already knows them. We could debate that. :-) I spend a lot of time every week dealing with Java NPEs. Seriously, you're right. Java is better for this. Writing good C requires a lot of background. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
Not to sound bitter, but it would have been nice to know about this sooner. This pretty much usurps what I and Eric Bischoff have been doing (when we can); I sort of figure it didn't get written in the last month either. Any reason for the blasted secretiveness? Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: December 13, 2002 12:09 PM To: [EMAIL PROTECTED] Subject: Sun XSL Formatter Peter did ask... The Sun xmlroff XSL formatter is written in C, and it uses libxml2 and libxslt plus the GLib, GObject, and Pango libraries that underlie GTK+ and GNOME (although it does not require either GTK+ or GNOME). The formatter currently produces PDF output only. xmlroff is a command line program, but the bulk of the XSL formatting is implemented as a libfo library that can be linked to any program that requires XSL formatting capability. It will be available under a BSD license. It is being developed on both Solaris and Linux. The formatter is awaiting final approval before the code can be made public source. An announcement will be made on xsl-list, www-xsl-fo, and XSL-FO@YahooGroups once the code is available. Regards, Tony Graham XML Technology Center Sun Microsystems Ireland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
Well, Java or C or C++ or Haskell, it would have been nice to have a clue. We have an ASF tradition of developing communities...this kind of stuff that Sun and IBM does is getting old. Don't open-source it; sell it. I will argue against its adoption into Apache. Arved -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: December 13, 2002 8:43 PM To: [EMAIL PROTECTED] Subject: Re: Sun XSL Formatter Arved Sandstrom wrote: Not to sound bitter, but it would have been nice to know about this sooner. This pretty much usurps what I and Eric Bischoff have been doing (when we can); I sort of figure it didn't get written in the last month either. Any reason for the blasted secretiveness? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Subject: Sun XSL Formatter Peter did ask... Tony, Thanks for the response. I must say, though, that had the product been written in Java, I would have been asking the same question as Arved. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Responses below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: December 10, 2002 5:56 AM To: FOP Subject: RE: Redesign issues Hi Arved, On Mon, 2002-12-09 at 20:30, Arved Sandstrom wrote: The feeling I got from my prototype is that there is not much commonality. Markers - there is no logic here that has anything to do with layout, per se. The content goes into a static-content and hence does not influence page break decisions. The logic for handling markers can be confined to the document level. root is an FO - it is the document, so it is the FO that can handle this. That is true but there is something that happened in the original way that fop handled markers. The fo has a property list which has a parent property list from the parent object. It also has a parent object. It couldn't be simply made null and then passed to the root as it could cause npe's. The argument here is not so much that it cannot be done, more that if it is a completely separate logic then it is easier to understand and ensure it won't end up with bugs or memory leaks. Right...I implemented the original (incomplete) marker logic using what we had at the time for property handling. I did not tackle the re-parenting problem at all - didn't get that far - so the marker content actually retained the inherited properties from the origin FO, which is incorrect. I see no problems with a marker handler that associates with the document, in this case. This would coordinate with page-sequences and pages, obviously. Incidentally, I still think that the way markers are described in the spec is vague and confusing. Perhaps we should hammer this out. Floats and footnotes - the float goes on a page or it doesn't. The footnote starts on page N and continues through N+x or it doesn't. What FO knows about pages? The page-sequence...that's the natural FO for handling float and footnote problems. OK, this is somewhat simplified; with floats it may come down to columns, and then it is the region-body that also needs to intercede. Tables I can't comment on. So there may be an argument here for independent layout managers. I think we could use layout managers when it is clear that there is a layout problem involving N FOs, such that those N FOs are not identical to the children of a higher FO. I see keeps as being the main occurrence of this. But even then, keeps are still related to logic that occurs in page-sequence and region-body and lines (3 entities, in other words), and the nature of that logic differs in all 3 situations, so is it worth abstracting out a keep manager? I don't know. There is the line layout manager. There is no line fo. The block layout manager is able to collect inline porducing layout managers and give them to a line layout manager which then has the logic to handle flowing inline areas into a line. The block layout logic is then more simple. Lines are not FO's, no - that's why I used the word entity. :-) This is similar to the cells under a table body. Also with page columns, do we want to make the FlowLayout manager handle all the blocks that do and don't span columns or can we create a page column layout manager which looks after blocks in columns and then can handle the reflowing etc. I originally handled this (in my prototype) with managers for pages, regions, spans and columns. This is the one area where I think managers make the most sense - the handling of a page is complex and it simplifies matters to have clearly distinguishable managers to take care of the various constituent areas. A leader with use-content creates an inline parent with a fixed width. It is creating a simple inline area but we want to do a quick independant layout for the content. Again, maybe not necessary but it help separate out the logic. Here's a common ground that I can agree on...pull the layout logic out, and put it in managers. This is not going to hurt. But really, really cut down on the urge to re-use managers through an inheritance hierarchy. I think this is also Joerg's point. It obfuscates more than it helps. I'm not sure the exact re-use problem you are referring to but I agree it should be simple and straight forward. Agreed. I won't comment further until I re-sync with the latest CVS and examine. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: December 9, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: Re: Redesign issues Keiron Liddle wrote: I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. Keiron, I'm inclining in this direction myself, because I am interested in isolating the layout/area tree functions as much as possible from the raw information stream of the FO tree. I tend to view the FO tree as a read-only data source for the layout. manaaged by the Fo objects. The feeling I got from my prototype is that there is not much commonality. Markers - there is no logic here that has anything to do with layout, per se. The content goes into a static-content and hence does not influence page break decisions. The logic for handling markers can be confined to the document level. root is an FO - it is the document, so it is the FO that can handle this. Floats and footnotes - the float goes on a page or it doesn't. The footnote starts on page N and continues through N+x or it doesn't. What FO knows about pages? The page-sequence...that's the natural FO for handling float and footnote problems. OK, this is somewhat simplified; with floats it may come down to columns, and then it is the region-body that also needs to intercede. Tables I can't comment on. So there may be an argument here for independent layout managers. I think we could use layout managers when it is clear that there is a layout problem involving N FOs, such that those N FOs are not identical to the children of a higher FO. I see keeps as being the main occurrence of this. But even then, keeps are still related to logic that occurs in page-sequence and region-body and lines (3 entities, in other words), and the nature of that logic differs in all 3 situations, so is it worth abstracting out a keep manager? I don't know. Here's a common ground that I can agree on...pull the layout logic out, and put it in managers. This is not going to hurt. But really, really cut down on the urge to re-use managers through an inheritance hierarchy. I think this is also Joerg's point. It obfuscates more than it helps. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Response below. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: December 7, 2002 7:16 PM To: [EMAIL PROTECTED] Subject: Re: Redesign issues [ SNIP ] Now the biggest issue: the layout managers itself. At the first glance it is not obvious why they should be first class objects at all, in particular as a cursory examination of the code shows a one-to-one correspondence to FOs both for classes and instances. Well, layout managers abstract the layout *process*, however, the deep layout manager class hierarchy is mainly designed around code reuse, which makes it really hard to understand. There is a reason that design rules recommend against overuse of inheritance for code reuse and deep inheritance hierarchies. There is only so much someone can hold in the brain. Nevertheless, this is something I don't know how to fix on the cheap. I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a hard to understand layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing maintenance stream FOP model. I'll have some more to say laterthese are immediate comments. I am just struck by the fact that it is now December 2002 and we are not where we want to be, not even close, which is providing an open-source Extended conformance XSL processor to the hungry, huddled and poor. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Still on for freeze deadline?
Considering that our new chief executive is Greg Stein, I'd be surprised if this isn't on the horizon. :-) -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: December 1, 2002 4:12 PM To: [EMAIL PROTECTED] Subject: Re: Still on for freeze deadline? Jeremias Maerki wrote: Moving around directories on the server so we don't lose history on files. See my proposal on directory structure reorganization, ex. moveing src/org to src/java/org. Any chance to get the ASF interested in SubVersion? http://subversion.tigris.org/ Apart from being accessible through firewalls, it allows moving files and directories, while being largely CVS compatible for everything else. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Alt-Design status: XML handling
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: November 26, 2002 3:25 AM To: [EMAIL PROTECTED] Subject: Re: Alt-Design status: XML handling Rhett, To comment on only two aspects of your posting. Rhett Aultman wrote: -Original Message- From: Oleg Tkachenko [mailto:[EMAIL PROTECTED]] Generally, event-driven processing is a pretty good thing. The critical issue with it, though, is the ratio of event production to event processing. If that number is anything greater than 1, then more events are being produced in a stretch of time than can be effectively processed in that stretch of time. Events start to queue up, taking up memory. If it happens enough, the heap starts to get a little too full, the gc runs a little too much, and that causes processing time to suffer even further. Under most circumstances, event-based processing is like using a garden hose to water a bed of flowers. It works just fine. Under more intense cases, though, it can be more like using a garden hose to fill a small container of water, then leaving the hose laying around (spilling water all over the lawn) while the container gets carried off somewhere. Actually, it really matters where the events are coming from. An HTTP server has no control over how many requests it gets, so your description above is apt. But for FOP (disregarding FOPServlet) everything is one process - the XML parser, the formatter, the renderer - so it's ultimately procedural; there may be an internal boundary where an event/callback system is used, but it's all one thread so nothing queues up at all. The only reason to adopt your approach (and I am not saying I don't like it) is because it's easier to understand. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
+1. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: November 20, 2002 5:23 AM To: FOP Subject: [VOTE] Victor as committer Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
Realistically I should be considered inactive myself. Thanks for bringing this up, Art. I just happen to have a brutal workload at the moment and I don't see it lessening in the next 4 months, minimum. It's fun stuff - I love it - but at the end of a workday I can't stand to look at code much, and same goes for weekends. I am not disinterested in Fop and will attempt to continue providing input. I haven't stopped monitoring the lists. But until such a time as I can contribute code I should be considered inactive. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: November 20, 2002 3:43 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Victor as committer Ok, I guess that answers my question. Sorry I was too lazy to look that up on my own. So my understanding is that only committers may vote, as per: A Committer has write access to the source code repository and gains voting rights allowing them to affect the future of the subproject. Putting this with the following: At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list I assume that being inactive means that I have lost my status as a committer and hence may not vote. So, hopefully one of these days (I have no idea when) I will again be able to contribute to FOP and re-attain committer status. At the moment, I am not actively working with FOP at work, but we are still using it (actually a version from a long while back - around the last time I contributed anything). The good thing is that I have not been called in to resolve any problems with FOP, the bad thing is that this is probably largely because of the limited use case. I hope in the future to expand this, which will likely entail some contributions to FOP. Or maybe by then my efforts will not be necessary - this would also be cool, although a bit disappointing in that I was not a part of it... Art (inactive) -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:18 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Victor as committer Venkata Rao Nadella wrote: Hi, I joined this list recently. I don't know anything about committer. Can someone let me know about committer? http://incubator.apache.org/drafts/glossary.html http://jakarta.apache.org/site/roles.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: A performance patch for PDFInfo class
-Original Message- From: Kevin O'Neill [mailto:kevin;rocketred.com.au] Sent: November 11, 2002 5:47 PM To: FOP Developers Subject: Re: A performance patch for PDFInfo class [ SNIP ] String buffers are used by the compiler to implement the binary string concatenation operator +. For example, the code: x = a + 4 + c is compiled to the equivalent of: x = new StringBuffer().append(a).append(4).append(c) .toString() So the first recommendation is to use String + for this type of method, it's easier to read and runs faster. [ SNIP ] This kind of thing is discussed by Jack Shirazi at length, also. The thing is, there has long been a blanket instruction, don't use String concatenation. Programmers learn it by fiat, and never think it through. In fact, it should be obvious to any programmer (if they are encouraged to think, that is) that concatenation of literal Strings is not something to avoid. Assuming a decent compiler. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: September 30, 2002 11:24 PM To: [EMAIL PROTECTED] Subject: Re: character Arved Sandstrom wrote: -Original Message- From: Tony Graham [mailto:[EMAIL PROTECTED]] Peter B. West wrote at 30 Sep 2002 13:28:18 +1000: Tony Graham wrote: [EMAIL PROTECTED] wrote at 27 Sep 2002 16:44:32 -0300: ... That means -, #12235 , etc are characters, while '1' is not. #12235; is a character reference. '#12235' is how you talk about a character's code point, although the hexadecimal representation is usually preferable. In XSL terms, '1' is a one-character string literal, but while you could claim that it is one character, there's no XSL conversion from a string to a character, so fo:character character='1'/ should fail. Tony, I don't think this gets us out of difficulty. A casual inspection Forgive me, but I wasn't trying to get anybody out of any difficulty, I was just trying to keep the terminology accurate. ... So how do I represent a character? To me, the cleanest, least ambiguous way is to represent a character attribute assignment value with 'character' - a string literal of length 1. Except that you know that that's not specified among the allowed conversions. The interesting thing is that 'character' doesn't appear in the productions in Section 5.9, Expressions, of the XSL Recommendation. Now there's a question for [EMAIL PROTECTED]! I think that you represent a character as a single character, e.g., character=c, or as a numeric character reference, e.g., character=#xA;. I agree with this last, after having digested everything. Point is well taken that we have some points to nitpick with xsl-editors, mostly about disambiguating some of the language. Arved, Help me here. I must be missing something. What is it that you agree with? That the spec, as worded, leaves us with character=c or character=#x63; which amounts to the same thing? Yes, this is what I agree with. If so, fair enough. Do you also agree that c is an NCName? And that character=- is a parsing error? Well, the production for NCName doesn't live in isolation, with reference to http://www.w3.org/TR/REC-xml-names/#ns-decl. Yes, c fits the production, but it's really an NCName when you have also declared the namespace. Why is character=- a parsing error? The XML Recommendation has at least one example of an attribute value that contains a hyphen. Maybe _I_ am missing something here. ;-) As far as I can see, the only immediate ways forward are to descend into the mire of context dependent parsing (which the editors have recently formally decided that we must do in respect of format) or apply our own disambiguating condition. How are you intending to implement character? By storing it as a Unicode value according to the XML Rec production Char::=#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] It will depend on the implementation library. ICU for example has UChar and UChar32 types. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: October 6, 2002 12:00 PM To: [EMAIL PROTECTED] Subject: Re: character Arved Sandstrom wrote: Why is character=- a parsing error? The XML Recommendation has at least one example of an attribute value that contains a hyphen. This comes from assuming that every unqoted sequence of characters which is not a number, mesutrement or a color has to be interpreted as NCName, as the grammar suggests, and IIRC a NCName must not start with a hyphen. This means hyphenation-char=- can't parse as number, can't parse as string, can't parse as color, can't parse as NCName - parsing error. Hi Joerg Can you cite the specific productions that lead to this conclusion? I am not saying that you are wrong but I can't find it. I must be tired. ;-) I just looked at the XML 1.1 production for AttValue which is AttValue::='' ([^] | Reference)* '' | ' ([^'] | Reference)* ' and I see a prohibition here on using a literal '' or '' in the attribute value, anywhere. But I see nothing about '-'. If the grammar of the recommendations leads to the conclusion that character=- is not OK, then this just simply offends my common sense. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: October 6, 2002 12:39 PM To: [EMAIL PROTECTED] Subject: Re: character Arved Sandstrom wrote: Can you cite the specific productions that lead to this conclusion? I am not saying that you are wrong but I can't find it. I must be tired. ;-) I just looked at the XML 1.1 production for AttValue which is Don't look at XML AttValue, look at the XSLFO property expression language. Somehow it is implicit that all attributes in a XSLFO document are parsed as expressions which are defined in 5.9 Expressions. Refer specifically to 5.9.3 Basics. A single hyphen is not a valid expression according to the XSLFO expression grammar. Maybe some fallbacks are implicit somewhere, I don't know. An Expr can be a Literal, the production for which is '' [^]* '' | ' [^']* ' If I look at the first alternative, '' [^]* '' it seems to me that I have pretty considerable leeway, and - isn't ruled out at all. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: October 6, 2002 1:29 PM To: [EMAIL PROTECTED] Subject: Re: character Arved Sandstrom wrote: An Expr can be a Literal, the production for which is '' [^]* '' | ' [^']* ' If I look at the first alternative, '' [^]* '' it seems to me that I have pretty considerable leeway, and - isn't ruled out at all. Erm, the expression is supposed to be inside the XML attribute quotes, for example hyphenation-char='-' would be ok (literal, second production), but hyphenation-char=- does not match the literal production, nor any other (except operator). Unless I missed something, of course. And unless _I_ am missing something, - precisely matches that production. You are looking at ' [^']* ' but I am looking at '' [^]* '' According to the latter I can absolutely do -. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: October 6, 2002 2:15 PM To: [EMAIL PROTECTED] Subject: Re: character Arved Sandstrom wrote: And unless _I_ am missing something, - precisely matches that production. You are looking at ' [^']* ' but I am looking at '' [^]* '' According to the latter I can absolutely do -. Well, in hyphenation-char=- the hyphen is the expression, not the hyphen surrounded by double quotes. As I said, unless I'm something missing, the FO property expression is the value of the XML attribute, which in turn is the hyphen, because the double quotes are part of the XML syntax and are stripped by the XML parser. The XSLFO property expression parser gets the hyphen, without any quotes, double, or single. And without the quotes, it does not match either of the two productions for literal. This is the problem here. Perhaps I should have written that hyphenation-char='-' and hyphenation-char='-' as well as hyphenation-char='quot;-quot;' are legal, while neiter hyphenation-char='-' nor hyphenation-char=- are ok. Yes, I see your point. I think they screwed up the grammar. As I stated before, I find it ludicrous that character=- would not be OK. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: Tony Graham [mailto:[EMAIL PROTECTED]] Sent: September 30, 2002 10:09 AM To: [EMAIL PROTECTED] Subject: Re: character Peter B. West wrote at 30 Sep 2002 13:28:18 +1000: Tony Graham wrote: [EMAIL PROTECTED] wrote at 27 Sep 2002 16:44:32 -0300: ... That means -, #12235 , etc are characters, while '1' is not. #12235; is a character reference. '#12235' is how you talk about a character's code point, although the hexadecimal representation is usually preferable. In XSL terms, '1' is a one-character string literal, but while you could claim that it is one character, there's no XSL conversion from a string to a character, so fo:character character='1'/ should fail. Tony, I don't think this gets us out of difficulty. A casual inspection Forgive me, but I wasn't trying to get anybody out of any difficulty, I was just trying to keep the terminology accurate. ... So how do I represent a character? To me, the cleanest, least ambiguous way is to represent a character attribute assignment value with 'character' - a string literal of length 1. Except that you know that that's not specified among the allowed conversions. The interesting thing is that 'character' doesn't appear in the productions in Section 5.9, Expressions, of the XSL Recommendation. Now there's a question for [EMAIL PROTECTED]! I think that you represent a character as a single character, e.g., character=c, or as a numeric character reference, e.g., character=#xA;. I agree with this last, after having digested everything. Point is well taken that we have some points to nitpick with xsl-editors, mostly about disambiguating some of the language. Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: September 26, 2002 11:41 AM To: fop-dev Subject: character Fopdevs, Any comments on the representation and parsing of character type attributes would be gratefully received. This came up on www-xsl-fo, because Eric Bischoff and myself had the same question. Tony Graham says that character should be a Unicode character, or Char. As in the actual real, encoded thing. Problem being, one property with a character datatype is defined in XSLT, which actually says that it's a Char. hyphenation-separator merely says that it's a specification of a Unicode character. I guess that could be interpreted the same way. But character for the character property says _code point_. And that is an integer value. So IMO the spec is currently very vague on this. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Style issues.
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: August 20, 2002 9:51 PM To: [EMAIL PROTECTED] Subject: Re: Style issues. [ SNIP ] The only encoding rule I'd realy like to have: Don't mix underscores with camelCase. Beside looking *really* ugly, it screws up Emacs' dynamic identifier completion, and I'd rather like to do something for FOP than fixing this. It comes down to ugliness, doesn't it? camelCase is nice. I haven't heard it before, and I agree with your admonition. This one is weird. :-) I have associated camelCase with Java, and expect to see it. I dislike Microsoft naming conventions for VB and C# (I guess you could call it capitalized camelCase, or Camelcase), without being able to say why. And for C I cannot abide anything but underscore separators and all lowercase. I think it is all a mater of habit. I may be a person who is ill-qualified to comment on variable names. I like assembler and machine code, and I never had a problem with the variable naming conventions for FORTRAN (I, J, K, L, M, N are INTEGER, etc). :-) Of course, I started with punched cards so I was overjoyed to actually have variables...sounds like a Monty Python skit (_you_ had _variables_?! I walked 10 miles both ways to school, uphill, in deep snow, and I had to hardcode the machine addresses on paper tape..._You_ had paper tape?! I lived in a culvert, didn't go to school, and flipped switches on vacuum tubes to set the program). Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tasks - layout
-Original Message- From: Karen Lease [mailto:[EMAIL PROTECTED]] Sent: August 19, 2002 6:58 PM To: [EMAIL PROTECTED] Subject: Re: Tasks - layout [ SNIP ] With regard to the line-height calculations, is anybody in the group interested in getting into the gory details of the baseline stuff for different scripts? I spent some time poring over the spec and trying to get a handle on this, but maybe it's too much detail for now. On the other hand, I'd really like to make sure that this version of FOP handles that stuff correctly as well as being able to do the various kinds of line-stacking strategies defined by the XSL-FO spec. I am definitely interested. I have put some thought into these things already. Granted, when I implement it'll be a different codebase but I am happy to work out the details on this list. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: just a thought
-Original Message- From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]] Sent: August 13, 2002 4:53 AM To: FOP Dev Subject: Re: just a thought Oleg Tkachenko wrote [ Snipped Oleg's proposal ] I thought I posted this two weeks ago. I made some measurements with the FOP examples and a few other FO files an get roughly the following statistics: 45% no child (mostly text nodes, but also fo:page-number and fo:region-*) 40% one child (many blocks and basically all inline FOs in the examples) 10% 2-5 children 4% 6-9 children 1% more than 9 children. Hmmm, maybe your subject line was ambiguous or confusing? Looks like we all missed that. :-) I overlooked the PCDATA as child case...taking that into account there is no doubt that 1 child is an important case. But I am still not convinced this case needs treatment different from the 2 or more children case as Oleg proposed. The FOText text node is the only subclass of FONode which is not a FObj. I considered moving the children vector to FObj and had it almost ready to commit but failed on a few issues which I think I have a solution now so that I can tackle this (in the maintenance branch) again. Constructing the children vector lazily is of course part of this. It is, however much more than just a null test in addChild(), because many FO classes access the children vector directly, every access has to be protected with a check for a null vector as well. Right, it is both adding and retrieving that needs checking. However, in the adding case it is the callee that is responsible for checking; in the other case it's the caller that needs to look at what it got back. Another thought in this regard: I was tempted to create an abstract FObjComposite which is the only one which can have children in the generic sense, and have FOs like fo:layout-master-set, fo:table and fo:page-number-citation no generic children at all (only typed children like fo:simple-page-master, fo:table-body etc. which are stored separately anyway, mostly in properly typed fields). The problem here is that this could interfere badly with extensibility. OTOH, what should be extension elements which are children of fo:layout-master-set, fo:table and fo:page-number-citation good for? I asked this already, without any response. I think this is a useful alternative. Using the DOM as an analogy, where we have either the Node-based view or the typed view (Elements, Attributes, Text, etc), the FO operations in Fop could be all quite generic (addChild(), getChildren(), hasChildren(), etc) or more targeted (addText(), addInline(), addBlock(), addSimplePageMaster() etc), or hybrid, as suggested above. I am partial to the use of typed children, including marker children. I am not a big fan of the generic approach, not any more (if I ever was). I don't think a typed child approach would interfere with extensibility, and I think the primary advantage is that the code is more self-documenting. Accessor methods could also be more specialized. Also, the sophisticated content-model checking that one needs to do with XSL is easier done, the sooner you move to explicit knowledge of what you are adding to what. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: just a thought
-Original Message- From: Oleg Tkachenko [mailto:[EMAIL PROTECTED]] Sent: August 12, 2002 8:16 PM To: [EMAIL PROTECTED] Subject: just a thought It's probably not too late to consider some trivial optimization of fo tree in redesign code. In a typical fo document probably about 30% of elements have no children or have only one child (text node usually), so instead of eager protected ArrayList children = new ArrayList(); in FObj.java we can consider lazy polymorphic member protected Object children = null; 1) For no chidren case it remains to be null. 2) For 1 child case it is FONode object. 3) For children case it is ArrayList. This means some additional logic must be implmented at addChild() and getChildren() methods. Any thoughts? Seems reasonable to me, Oleg. The default constructor for ArrayList creates an array of 10 Objects. An inexpensive check for null in addChild() is unlikely to cost more, even over many children, especially averaged over an entire document. Case 2 might be overkill, unless one can make the case that single children are frequent enough to make this extra logic worthwhile. Comments? Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Flow and region-body
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: July 23, 2002 11:12 PM To: fop dev Subject: Flow and region-body Hi, I'm about to remove some hackery from the maintenance branch, as part of a general cleanup. There is a comment in Flow.java (soon/now AbstractFlow.java) // flow is *always* laid out into a BodyAreaContainer I was not able to find support for this directly in the spec, although I think this is reasonable. Can anybody comment on this? I nail this down for now, apparently this is how FOP currently works anyway. Actually, routing static-content into a body region causes FOP to loop, and if neither the flow nor static content go into the body a no flow found is logged/thrown. J.Pietschmann I believe I had something to do with this. :-) Basically, you're right - there is no direct support in the spec for the assertion that fo:flow content must go into fo:region-body child areas, and fo:static-contents go into the 4 other regions' child areas. I think it is clearly the intent of XSL 1.0, however, that fo:flow content go into fo:region-body, and fo:static-content go into the other 4 regions. After all, it is impossible to look at the specialisation of fo:region-body and not realise that it occupies a special position in the region pantheon. Down the road, with XSL 2.0, we may see some generalisation of flows of the fo:flow type, and have more flexibility than just one single fo:region-body. Regards, Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [UML]: Poseidon license key
-Original Message- From: RamanaJV [mailto:[EMAIL PROTECTED]] Sent: July 17, 2002 11:12 AM To: [EMAIL PROTECTED] Subject: [UML]: Poseidon license key HI All, I have installed Poseidon 1.3.1 and it is asking me for the license key when I start it. But, I couldn't find anything like that in the home directory of Poseidon. Please, help me. Hi, Ramana Right off Gentleware's website, for Poseidon CE: First start of Poseidon During startup, Poseidon expects to find a key file called 'InterimPoseidonCE.key' in the installation directory 'poseidon1.3', in 'poseidon1.3/bin' (this is where the installation puts it), or in your home directory. All configuration files are put in the directory 'poseidon/CE' in your home directory. If you want to set another home directory for Poseidon's configuration, set the environment variable POSEIDONCE_HOME prior to starting Poseidon. At startup, you can register with Gentleware to receive a final key for PoseidonCE. The shipped interim key runs for 1000 days, the final key is unlimited. I just downloaded and unzipped the latest, and the interim key file is certainly present, in the bin/ directory. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Usage of UML Diagrams
-Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: July 8, 2002 12:45 PM To: FOP Subject: Re: Usage of UML Diagrams Thats a good idea. [ SNIP ] We haven't had success with UML in the past but that doesn't mean anything. If you feel this could be useful area to explore, go ahead. The tools such as ArgoUML have improved and I just tried it out again. We never tried it that seriously. And the last time we did, ArgoULM aka Poseidon CE wasn't quite there yet. I agree that now it probably is. It wasn't (and isn't) fair to rely on high-powered stuff like Visio or TogetherJ that most people don't have easy access to. Nice thing about ArgoUML is that the XML file format is great as source to put into CVS. I second the general comments, that this is worth doing. At the moment I am in the same boat as lots of other people, i.e., I don't comprehend the current HEAD codebase that well, and anything that helps is welcome. Regards, Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [vote] removing BufferManager and XTTreeBuilder
-Original Message- From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]] Sent: July 4, 2002 9:48 AM To: FOP Dev Subject: [vote] removing BufferManager and XTTreeBuilder Hello all, there is some dead wood to cut: - The BufferManager isn't used anymore, because it apparently caused more harm than good (see Mark Lillywhite's comments) +1 for removing all references and delete the files in fop/system - The XTFOTreeBuilder provides a SAX1 interface. It is not used anywhere, the Driver uses the FOTreeBuilder SAX2 interface. Does someone remember questions about SAX1 support? If not: +1 for removing XTFOTreebuilder and XTElementMapping +1 on both. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence short or long
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. Arved -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: June 27, 2002 7:29 AM To: [EMAIL PROTECTED] Subject: Re: Licence short or long 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence short or long
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: June 26, 2002 5:42 PM To: [EMAIL PROTECTED] Subject: Licence short or long Hi committers I think I need to bring up a subject that not so comfortable but that has to be brought up again IMO. On the Avalon dev list they fight again between long and short licences in source code. We have the short form but it seems like we have to switch (back?) to the long form. Here's the link to the discussion: http://marc.theaimsgroup.com/?t=10250974725r=1w=2 What do you think? It's news to me that the board changed their mind. I'm not saying that they did not, it's just I haven't heard that they now forbid the short form. I'll see what I can find out. And in fact the short form was explicitly okayed some time ago. When we decided to switch over it wasn't just an off-the-cuff haphazard decision. Personally I think the long form stinks. Every source file I open from an ASF project I immediately have to scroll down 1 or 2 pages to see actual source. And just copying and pasting the long Jakarta license into a text editor I see that it is 2700 bytes. Multiply that by 500 source files or 1000 source files and you have 0.5 MB or 1 MB (uncompressed) of garbage when a simple short pointer to a _single_ long license in the distro ought to be enough. These were both points that have been expressed before and I think they are still valid. But that's common sense. When did licensing ever mesh with common sense? :-) If we have to switch back to the long form, oh well. Not much choice there. Regards, Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Using bugzilla
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: June 20, 2002 11:00 PM To: fop-dev Subject: Using bugzilla 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.) ?? Preaching to the converted... :-) Sort of. We use Merant PVCS Tracker at work, which is a nice piece of gear. It does defect tracking and issue management. Bugzilla is a capable enough system also, as you've noted. The major stumbling block to all of these systems is that users subvert them. Not maliciously, but the effect is the same. Everything turns out to be high priority...there is no change control board so everything gets sent to developers as it arrives, with no screening. Developers apply their own notions of what the requirements are and frequently decide that reported behaviour is OK. If they _do_ accept that it's a bug, developers often close the defect before QA ever has a chance to verify. :-) And on and on it goes. I've never seen a commercial issue tracking system successfully used for issues, and I have now seen a few. Mostly they get ignored...people prefer mailing lists. I think there is some psychology there that I have not quite fathomed; partially it's also due to the fact that folks are most familiar with email. So I am not disagreeing with you, so much as I am suggesting that 75% of this is process, and if you can get people to buy into the process then any system will work, whether it's mailing lists, defect/issue tracking software, or even shared ASCII files (assuming access). The main thing is that there need to be some immediate rewards: 1) better feedback, 2) more feeling of having contributions noticed, and 3) tangible results. I happen to think mailing lists are pretty poor for issue management, so I think it is worth a shot. I am amost completely engaged with the other project at the moment but I haven't left FOP but temporarily; my main problem at the moment is keeping abreast of the lists and maintaining a clue as to what is occurring, and maybe your idea would help. I'd certainly make the attempt. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: manifest classpath (was: Re: delay for release candidate)
-Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: June 10, 2002 1:20 PM To: [EMAIL PROTECTED] Subject: manifest classpath (was: Re: delay for release candidate) Arved Sandstrom schrieb: Christian, if it's not already changed, this release would be a good opportunity to modify the manifest file Class-Path so that it does not expect JARs inside a lib/ directory. As was discussed some time back this is awkward for a number of J2EE servers. If nothing else it can lead to a redundancy of XML parsers and XSLT processors. Easiest way to do this and still maintain organisation is to expect fop.jar to be co-located with the JARs that it needs. So just removing 'lib/' is ok ? Yes, that's all that's required in the manifest. This provides maximum flexibility. If the referenced JARs were entirely our own it would be a different matter - we could put them where we like. But in many deployments we ought not to constrain the locations of common JARs like this. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign Goals and XSmiles
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: June 5, 2002 3:42 AM To: [EMAIL PROTECTED] Subject: Re: Redesign Goals and XSmiles I've heard about XSmiles but never tried it. It's somewhat surprising that noone from that project ever contacted the FOP team. They have, actually. :-) I believe the mail archives will reflect that. There were the first expressions of interest in cooperation but it was not really pursued. By either side. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign Goals and XSmiles
I'll see what I can locate. It's useful to have the earlier history in mind if we decide to talk to them now. Arved -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: June 5, 2002 8:11 AM To: [EMAIL PROTECTED] Subject: Re: Redesign Goals and XSmiles Oh. I stand corrected. But looking at marc.theaimsgroup.com, I find nothing when searching for XSmiles. I've heard about XSmiles but never tried it. It's somewhat surprising that noone from that project ever contacted the FOP team. They have, actually. :-) I believe the mail archives will reflect that. There were the first expressions of interest in cooperation but it was not really pursued. By either side. Cheers, Jeremias Märki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: build changes
-Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 24, 2002 6:29 AM To: FOP Subject: Re: build changes 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. 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. [ SNIP ] 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. 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. Also this doesn't really scale with more developers. Part of the reason can be seen from the resources available to the trunk code. Gump provides a compile and project compatibility check. People can grab a nightly download to check and use the latest build (admittedly broken right now). Other developers can see the changes directly. I don't think protecting people from problems will lead to the solution of those problems. I tend to agree with Keiron on this, Peter. You're right, the CVS tree is not sacred, but the development model you advocate is not the usual one. For the reasons that Keiron states. Another good reason for branches is planned development that is out of sync with other planned development. That is, one or two developers have a major feature to work on, over a month or two, that is going to straddle a number of releases, and they simply will not have working code available during that time period, and what they are doing would actually affect functionality if it were to be in the main branch. But with this major exception I can't think of any other situations, apart from the release maintenance scenario, where a branch is really called for. Just my opinion. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Keiron Liddle Elected To ASF
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. :-) Regards, Arved __ Arved Sandstrom Sr Software Developer Platform Products Group Halifax RD Office Hummingbird Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: build changes
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 24, 2002 9:23 PM To: [EMAIL PROTECTED] Subject: Re: build changes What approach is taken in the places you mention to the identification of binary components? Version information is included in the Manifest.mf of all JARs. We use Manifest attributes that are made available by Java for installed optional packages, like Implementation-Version. This includes versioning, build number, and product code. It is all automatically done, and if it's an actual release then there is a label in VSS that maps to this. JARs also include any shared libs/DLLs. These also get built at the same time as everything else. It's not perfect but if a customer reports problems with a JAR we have enough info to track back to source. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Why do links generate multiple rectangles in PDF?
Hi, Adrian It's been quite a while but I recall that at the time that basic-link code was written (long enough ago that they were still called simple-links) there was an option to choose between link rectangles per word, which aws intended more as a debugging setting, or combining link rectangles into larger rectangles where possible (that is, if the geometry permitted). It was certainly the intention (and I believe it worked this way) that a number of linked line areas all with the same inline-progression dimension would result in _one_ linked rectangle. As one example. So that's your answer. :-) The multiple linked areas are an ancient debugging artifact, that seems to have become the norm. Regards, AHS -Original Message- From: Adrian Edwards [mailto:[EMAIL PROTECTED]] Sent: May 22, 2002 4:08 AM To: [EMAIL PROTECTED] Subject: Why do links generate multiple rectangles in PDF? Can anyone (Arved?) give me a brief explanation of why one fo:basic-link will generate multiple link rectangles (one for each word!) in a PDF rendering? This would seem to have a dramatic effect on the file size of larger PDF documents with many multi-word links. It's such a (seemingly) strange behaviour that there must be some justification, although I can't find it in the mailing list archives. Any help appreciated. Adrian Edwards Application Developer Netimpact Online Publishing http://www.netimpact.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Why do links generate multiple rectangles in PDF?
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 22, 2002 6:07 PM To: [EMAIL PROTECTED] Subject: Re: Why do links generate multiple rectangles in PDF? Arved Sandstrom wrote: So that's your answer. :-) The multiple linked areas are an ancient debugging artifact, that seems to have become the norm. The annoying part is that the link area excludes the whitespace between the words. Or is this intentional? Line breaks and in particular hyphenation in a link aren't handled properly either. J.Pietschmann Excluding the WS was intentional in the sense that it was intended to show the individual wrapping of linked words, during debugging. By now I am not surprised that other stuff is out of sync. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: garbage collection on reset
Hi, Torsten All points are noted. I am not sure I understand what you want to see in the case of modified images. In the general case, as soon as you change the dimension of an image, you might potentially have to recalculate _all_ layout. The rendering cannot independently start using a new image size. I think I am missing something. Can you describe this scenario in more detail? It sounds like a good use case. Regards, Arved Sandstrom -Original Message- From: Torsten Erler [mailto:[EMAIL PROTECTED]] Sent: May 15, 2002 6:23 AM To: Fop-Dev (E-mail) Subject: garbage collection on reset Can I (and if yes, how can I) configure the MEM_PROFILE_WITH_GC variable on StreamRenderer to run garbage collector every start and finish to save memory on batch printing? Additional, please take a look on FopImageFactory. This class holds strong references to every loaded image. No reload and recalculate the dimension of the image (which has modified since the last loading) is possible at any time. This is the cause why modified images are scaled to the size of the first loaded image on awt/print rendering. I've overriden the class to disable the caching complete (Batch printing uses 500++ MB!!! memory usage after loading 20 to 30 images and it crashes due to OutOfMemoryError). I don't know whether this is fixed in your current project status, if yes ignore this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Line breaks and other typographical stuff (was: Re: Latest FOP schema)
-Original Message- From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 14, 2002 7:52 AM To: FOP Dev Subject: Line breaks and other typographical stuff (was: Re: Latest FOP schema) I found them online, the relevant URLs appear to be http://www.unicode.org/Public/UNIDATA/LineBreak.txt http://www.unicode.org/Public/UNIDATA/extracted/DerivedLineBreak.txt and for the interpretation of the codes http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt (the lb section) I still think this area is somewhat unintuitive to browse. Does somebody know where there is a more elaborate explanation of the values used there, in particular whether there is a formal description how they are supposed to influence the actual line breaking? I don't want to rely on intuition here, it fails me much to often... This would not be covered in UTR 14, Line Breaking Properties? (http://www.unicode.org/unicode/reports/tr14/). Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Line breaks and other typographical stuff (was: Re: Latest FOP schema)
-Original Message- From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 14, 2002 7:52 AM To: FOP Dev Subject: Line breaks and other typographical stuff (was: Re: Latest FOP schema) Well, if we are at this, another typographical nastyness which comes to mind is an indented initial. This bothers me for quite some time now: How should this be expressed in XSLFO? In HTML, a floating table around the letter can be used, but this seems awkward and does not account for fine tuning like the outdent to account for serifs. Also, the automatic displacement of the next lines could be a problem. I think there is also a float necessary in XSLFO, perhaps with some adjustments to the width and with relative positioning for fine tuning. text-indent. If that's not it, what do you mean by indented initial? Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Line breaks and other typographical stuff (was: Re: Latest FOP schema)
A drop cap, in other words. :-) -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 14, 2002 4:47 PM To: [EMAIL PROTECTED] Subject: Re: Line breaks and other typographical stuff (was: Re: Latest FOP schema) Arved Sandstrom wrote: text-indent. If that's not it, what do you mean by indented initial? I meant what the following HTML snippet shows: table width=300 tr td table align=left cellpadding=0px cellspacing=0px border=0px trtdspan style=font-size: 200%; L/span/td/tr /table porem ipsum dolor sit amet. Consectetuer adipiscing elit, sed diam nonummy. Nibh euismod tincidunt ut laoreet dolore magna. Aliquam erat volutpat. Iriure dolor in/p /td /tr /table J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: AW: Latest FOP schema
Comments intermingled. -Original Message- From: J.U. Anderegg [mailto:[EMAIL PROTECTED]] Sent: May 13, 2002 5:15 AM To: [EMAIL PROTECTED] Subject: AW: AW: Latest FOP schema J. Pietschmann wrote: fo:block are Rectangular areas, perhaps indented and with border, padding and other individual traits, nested into a rectangular area. I understand setting traits, properties. How about page layout, setting inline and baseline postitions? Does it imply a unconditional CRLF? It's not that there is a CRLF, or anything like it, after a block, but rather that if it is succeeded by block-level siblings that they will be stacked in the block-progression-direction, so the effect will be the same. Can you be more specific with respect to the other questions? What does the input below look look like on the page? fo:block level_0_text fills to position A fo:block level_1_text positioned at A fills to position B /fo:block more level_0_text positioned at B /fo:block 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 fo:block level_0_text fills to position Afo:block level_1_text positioned at A fills to position B /fo:blockmore level_0_text positioned at B /fo:block then it would still be the same. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments down under... -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 7, 2002 4:40 AM To: [EMAIL PROTECTED] Subject: RE: [REDESIGN] Line layout manager discussion On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote: From a practical viewpoint it makes sense to wrap the block in an inline area with the traits and treat the block normally in layout terms but it still feels uncomfortable. It also introduces a whole lot of other questions about line height, padding etc. The use of line-height for inlines is as a synonym for height; one _can_ use height but only for replaced inline-level FOs. So for an original inline, say, we'd ignore a height but use line-height instead, which more often than not is just going to inherit from the block containing it. I think this is pretty straightforward. I don't know if this is what you were getting at, though. Because I figure you're on top of this already. I was referring to the line-stacking-strategy. If it is font-height then It has the same block-progression dimension for each line-area child of a block-area. This means that if we embedd the block within a line area then the line is still the same height as other lines. So even if the block is big enough to fill a page it will be placed in a line area that has the same height as as other lines with only text. font-height has the same effect on other things also, though, where a person may have some expectation that the element has a larger size. Like external-graphic, for example. Which is why a note in Section 6.6.5 even says that one normally uses max-height (the default) or line-height for this FO. I think this is a situation that would be cause for a runtime warning, using some kind of heuristics - the user has imposed conditions on the FO that really don't go well together. Something that big they should maybe think of doing a float. But the spec itself is reasonably clear on what we can expect from font-height, I think. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Interleaved commentary... -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 6, 2002 5:21 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Hi All, What it boils down to seems to be if the inline fo returns the block area or generates an inline area that contains the block area. If it generates an inline area then it will set traits on that area (border, background, link, padding etc.). From 4.7.3 my understanding is that any (normal) areas returned by children of the inline formatting object always become children of normal inline areas that the FO generates. Similarly for a block, by 4.7.2. So the inline FO can never _return_ a normal block area. I guess it depends on one's understanding of return. I take this not to include any nested areas. The normal block area comes back, sure, but as a child of a normal inline area. If that is the case why is a footnote inline not allowed to have a block level child. Since this is effectively the same as using an inline-container. Probably just the semantics of what the inline does for a footnote, rather than any technical reason. Here is another confusing statement, that makes sense for inline-container. 4.6 The dimensions of the content-rectangle for an inline-area without children is computed as specified by the generating formatting object, as are those of an inline-area with block-area children. Does computed as specified mean specified on the fo or derived from the context. I'm thinking, as specified on the FO. From a practical viewpoint it makes sense to wrap the block in an inline area with the traits and treat the block normally in layout terms but it still feels uncomfortable. It also introduces a whole lot of other questions about line height, padding etc. The use of line-height for inlines is as a synonym for height; one _can_ use height but only for replaced inline-level FOs. So for an original inline, say, we'd ignore a height but use line-height instead, which more often than not is just going to inherit from the block containing it. I think this is pretty straightforward. I don't know if this is what you were getting at, though. Because I figure you're on top of this already. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 5, 2002 12:55 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion 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 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. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Border properties
Comments intermingled.Default reference orientation and lr-tb writing mode assumed. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 5, 2002 1:34 PM To: fop dev Subject: Border properties Hello, I tried to make something out of bug 684. Again, after reading the spec in depth, I'm nearly biting pieces off my keyboard. In the tables.fo examples, the left edge of the table content rectangle is the same as the edge of the reference area, and left border (should I use start edge border?) is tacked on so that it extends outside the reference area. What it really boils down to is, the start-indent and end-indent are content-rectangle to content-rectangle distances. If the start-indent is zero then borders and padding and space are outside the content rectangle of the reference area. Similarly for end-indent. The upper and lower border, however, do not overlap previous or following blocks, as expected. I would not expect this - see below. At least not with initial values. Well 4.4.1 says the start-edge of its allocation-rectangle ... offset from it inward by a distance equal to the block-area's start-indent plus its start-intrusion-adjustment (as defined below) minus its border-start, padding-start, and space-start values... given that the start-indent of the tables are zero (hopefully), the behaviour regarding the border extending left beyond the edge of the refernce area appears to be consistent with the spec, albeit IMO a bit counter-intuitive, because not consistent with what happens in BPD. The treatment is different; there is no BPD counterpart to start-indent and end-indent. The separation between content-rectangles is determined by padding+border+space (before after). Borders and padding are length-conditional values so unless they are at the leading or trailing edge of a reference area they will definitely have the specified length. None of them are negative. The spaces _can_ be negative so this is the sole mechanism by which areas (including borders padding) can overlap (and space-specifier resolution is involved of course). Now, what is the problem bug 684 complains about? Does it mean the border in BPD should be handled similarly to what happens in IPD? Or does he mean something else? And, of course: is my understanding on how borders/padding should be handled resonable? I feel very confused. Join the club. :-) I constantly remind myself of what the definitions really mean in simple language. I also try to minimize use of allocation rectangles - I understand the concept but find it confusing. BTW what happens if both start-indent and margin-start were defined on the same block area? margin-* properties are absolute only (top, bottom, left, right). In any case, according to 5.3.2 and 5.3.1 the absolute properties take precedence. margin-left if explicitly specified has priority over start-indent. I took a quick look at table.fo (the FO) and I think this will probably help out. I have to admit if there is one area of the spec that I am not particularly familiar with it is tables - in this case I don't think there is any weirdness involved stemming from table border properties. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 3, 2002 9:31 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Hi devs, Be careful with the abbreviations. :-) One small slip of the keys and we'll all be referred to as debutantes. I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). I couldn't tell from the SVG source what you prepared the file with. I would like to use SVG myself. There is no way I am going to handcode it, though (just as with FO). Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 11:26 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Karen Lease wrote: [ SNIP ] 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. I am off to work so cannot comment more at the moment, on anything. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 3, 2002 10:42 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion [ SNIP ] 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. [ 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. Because in the conceptual tree block areas have a well-defined location and there is no bubbling up at all. Whereas in the real tree we can flatten completely and not have a tree at all, so we could have maximal bubbling. As far as semantic information, are we talking about during layout or once the area is passed off for rendering? Because it seems to me that if we have managers then they can take care of retaining the semantic information (e.g. all areas generated or returned in this manager belong within a link). Once the areas are passed off to the renderer practically all the information needed to properly render any area can be expressed as traits on that area - one main exception is that areas need to know their nearest ancestor reference area for positioning. I am not discounting an area tree per se - with my xslfo-proc project I find an area structure (partial in my SAX implementation) to be the most convenient way of recording current layout information. That is, manager X needs to store certain information and it may as well use Area objects to do it. But I lean strongly towards a viewpoint where the areas have no knowledge of original semantics. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments inline...actually, no, they're not, they are really block-stacking, but you get the drift. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: May 2, 2002 7:21 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion 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. Good...if we all agree with that then I think it is the main point gotten out of the way, because every other situation has to do with child FOs all being inline or block-level, for which the results are less dubious. 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. The main thing is, let's make sure that we have agreement (codified through use of these diagrammed examples) on all matters that affect placement. I understand that we want to have a warm fuzzy about our understanding of the spec, but that's not going to happen with everything. To be precise, if I can get a number of these examples created, what we can do is identify situations where we can say, this one is 100% solid (we know this is right, there is no uncertainty in the spec), this one is iffy (there may be small inconsistencies between our placement and what the spec authors intended), or this one is problematic (contradictions, for example). Once we have classified the examples, we can do damage control on the uncertain ones. Namely, let's do it this way, but let's be aware that things could be interpreted another way, and if so, how heavily committed are we in our code? On a related matter when it comes right down to brass tacks I am really only concerned about placement (accuracy of rendering). Both with Fop and with my other project I find it easier to use the conceptual areas, and I get the sense that others also feel this way, but let's face it, as long as our final result is consistent it doesn't really matter if our internal structures deviate. - 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. On this particular point I think we are fortunate insofar as it is not going to affect placement. 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! As Keiron says, if the spec writers had been clearer, we wouldn't have to spend hours chasing our tails like this! I find the transitions from relatively formal set-oriented treatments to casual prose disconcerting. As soon as I see formal then my Pedant-O-Meter cranks way up, and I find it hard to switch off. :-) Regards, Karen Arved Sandstrom wrote: [SNIP] _If_ there were blocks nested inside the top-level block these would produce normal block areas that are single children of normal block areas produced by the top-level block. My reading of Line-Building is that normal block areas generated by a fo:block have either _single_ block areas _or_ one or more line areas as children, not a mixture. Final comment: it is the close intermingling of inlines and blocks in this example that causes so much line breaking. Clearly each of the 2 nested blocks could be wrapped in inlines (fo:inline or whatever), and as a result everything in the example, in theory, could be in _one_ line area. Anyhow, please critique away. :-) Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: What the spec says about table-row, table-cell etc.
Comments below. -Original Message- From: Chuck Paussa [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 7:16 PM To: [EMAIL PROTECTED] Subject: What the spec says about table-row, table-cell etc. I've been working on a schema for FO documents so that I can off-load the validation chore. I created the schema from the W3C documents which state the following for table-cell: Contents: (%block;)+ In addition this formatting object may have a sequence of zero or more fo:markers as its initial children. The following properties apply to this formatting object: * [7.4 Common Accessibility Properties] * [7.6 Common Aural Properties] * [7.7 Common Border, Padding, and Background Properties] * [7.12 Common Relative Position Properties] * [7.26.1 border-after-precedence] * [7.26.2 border-before-precedence] * [7.26.4 border-end-precedence] * [7.26.6 border-start-precedence] * [7.14.1 block-progression-dimension] * [7.26.8 column-number] * [7.13.4 display-align] * [7.13.6 relative-align] * [7.26.10 empty-cells] * [7.26.11 ends-row] * [7.14.4 height] * [7.28.2 id] * [7.14.5 inline-progression-dimension] * [7.26.13 number-columns-spanned] * [7.26.14 number-rows-spanned] * [7.26.15 starts-row] * [7.14.12 width] FOP, in addition, both allows and implements the setting of block's inheritable attributes such as color and text-align which are then propagated down to the enclosed blocks. My questions are as follows: Is there a place in the spec that says Containers may hold inheritable attributes so they can be passed on to their child objects? Or is this just a side-effect of inheritabliity? Or is this illegal and will disappear in future FOP versions to be compatible with the spec? Yes, at Section 5.1.4. Every inheritable property exists on every formatting object, whether or not the property is actually applicable to (useable by) that FO. This isn't just a side-efefct of inheritability, this _is_ inheritability. :-) and Is there a list of these inheritable attributes ? Or do I just generate the list from those attributes that have an enumeration value of inherit? Don't do the latter...what you want to want to look at is the Inherited: field in the property descriptions. Chuck, one thing you may find helpful (maybe you've done it already) is to work off the XML version of the spec, and extract the property tables, at which point you can do SAX or XSLT to get at interesting bits. This was my approach. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments inline. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 1, 2002 2:19 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion [ SNIP ] Look at basic-linka paragraph of text blockwith a block/block and more text/basic-link 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? There were many discussions last year, as I recall, that espoused this viewpoint, that the area rules precluded a number of FO-level combinations and juxtapositions. This school of thought, and I belong(ed) to it, held that a block or inline contains either block FO children _or_ inline FO children, but not both. I am no longer convinced that this needs to be the case. It is certainly safe to ensure that all the children of a given FO are either block-level FOs _or_ inline-level FOs. In these cases we have area generation and layout which is (I think) well understood. But this treatment shows, I think, that the area rules can be satisfied without having to homogenize the type of FO children. 4.2.1 is a restriction on areas, as you know. Certainly the areas that I have diagrammed do not violate this constraint. 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? I'll have to take a look around. I happened to use Visio because it's on the machine and I'm familiar with it, plus it's a nice piece of gear. The most recent Visios do SVG, I believe, but I don't have a copy at home. We could use Postscript as well. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments inline. -Original Message- From: J.U. Anderegg [mailto:[EMAIL PROTECTED]] Sent: May 1, 2002 5:19 PM To: [EMAIL PROTECTED] Subject: AW: [REDESIGN] Line layout manager discussion Questions: o A basic-link in PDF means an annotation - an annotation defines a rectangle. What's the effect, if the annotation text breaks to a new line? If the basic-link contains more blocks and children? From the XSL standpoint it's merely a question of the basic-link generating one or more normal inline areas. These map to annotation rectangles in PDF. When the inline areas in question are presented to the renderer they have behaviour traits corresponding to the internal-destination or external-destination. o Middle Easterner write left-to-right, top-to-bottom. Far Easterners write from top-to-bottom, right-to-left. They have their own font metrics. Is the FOP pagination able to handle this? How does it affect the area tree and the document presentation? Can it handle this right now? No. Apart from things like mixing text with different writing-modes, supporting different writing-modes and reference-orientations is actually not much more complicated than the specific Western case, at everything except the immediate glyph-area level. o fo:external-graphic: can text be flowed around an image? That means, does it make sense for a user to mix text and images within the same block - unless a table is used, but this is a different setup. Using a side-float is the best you can do with XSL 1.0. If you are looking to do something like TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT -- TEXT TEXT TEXT TEXT || TEXT TEXT TEXT TEXT | Image| TEXT TEXT TEXT TEXT || TEXT TEXT TEXT TEXT || TEXT TEXT TEXT TEXT -- TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT then, no, without tables and a fair bit of tweaking I don't think so. An external-graphic intermingled with PCDATA is going to normally cause the line it is in to expand to its own size (using line-height or max-height for the line-stacking-strategy), so things will look like TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT -- || | Image| || || TEXT TEXT || TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT assuming that the baseline of the external-graphic is determined by an auto value on alignment-adjust. Hope this helps. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
; _If_ there were blocks nested inside the top-level block these would produce normal block areas that are single children of normal block areas produced by the top-level block. My reading of Line-Building is that normal block areas generated by a fo:block have either _single_ block areas _or_ one or more line areas as children, not a mixture. Final comment: it is the close intermingling of inlines and blocks in this example that causes so much line breaking. Clearly each of the 2 nested blocks could be wrapped in inlines (fo:inline or whatever), and as a result everything in the example, in theory, could be in _one_ line area. Anyhow, please critique away. :-) Regards, Arved complex_block.png Description: PNG image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Committing html
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. Arved -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 28, 2002 7:58 PM To: fop-dev Subject: Committing html 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: line layout commit
I have some thoughts and suggestions, some of which we might adopt with varying degrees of success. 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. 2. Can we do better with CVS? Maybe...reserved checkouts is overkill but perhaps watch features are indicated. We currently get commit notifications (I suspect through loginfo, probably, rather than a watch feature), but we don't know when someone started work on a file. 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. I would nevertheless suggest maybe trying the watch features. I would otherwise really stress the use of a single-point-of-reference file, like STATUS, but I have my doubts about that. It has not proved out so far. What would be really sweet is if we had a visual aid that supplemented cvs watch features, maybe a page on the website that you could access that would indicate that a certain developer has run 'cvs edit' on file A, for example. Maybe ViewCVS does this already, I don't know. 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. Comments? If folks are agreed or at least not against it I can set up what needs to be setup. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: April 27, 2002 12:20 PM To: [EMAIL PROTECTED] Subject: Re: line layout commit [ SNIP ] At any rate, I'm certainly not averse to having some more structured kind of communication about where to go from here be that a chat or just some discussion on the list of where we are and where we should go. As I mentioned, I'm going to dive in to his new stuff and study it carefully today and tomorrow; I'll probably have some questions and remarks at that point. [ SNIP ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: line layout commit
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. :-) As far as the Unicode bidi algorithm is concerned, yup, no kidding. :-) Have you looked at the Java reference implementation for it? :-) Not a trivial thing. Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 26, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: line layout commit 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. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. The main things that need thinking about are: - range properties - wrapping (ie. no wrap) - whitespace and linefeed handling - Unicode BIDI (this looks hard) It is very rough at the moment, the idea is to get a basis so that inline areas can be created and put into line areas and this will fit into the overall design. This leaves us with a simpler way of handing inline areas. So whats next? It is possible to start looking at fully implementing inline areas, eg. image, instream-foreign-object, leader, character. Getting pagination working will be a big step forward. Then we need to block area layout managers, like tables and lists. So what do people think? Regards, Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
background-image patch v0.03 in CVS
What it says. It builds, and I ran a few simple tests. I'll be standing by to do any further fixup work or to add more related features. Regards, AHS __ Arved Sandstrom Sr Software Developer Platform Products Group Halifax RD Office Hummingbird Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Interesting Aside
I thought this was rather interesting. There is an article on XML.COM entitled Government and Finance Industry Urge Caution on XML (http://www.xml.com/pub/a/2002/04/24/gaonacha.html). Lest we start thinking of XSL as a second-best W3C Recommendation that is viewed slightly askance by many in the XML community (which I think it is :-)), consider the fact that the US government, in the report cited in the article, clearly mentions XSL 1.0 in its discussion of core XML standards (pages 18 34 in the PDF document). I think this is encouraging. Probably for all developers _and_ users. A lot of the other XML technologies out there are getting the limelight, but when it comes right down to it XSL-FO is a solid spec for a solid requirement - producing good-looking paper from XML. Let the other people have fun with Web Services and RDF and schemas - I am perfectly happy with a relatively stable spec that _definitely_ has a strong business case. :-) If you read the report, incidentally, the GAO is not urging caution with respect to XML, per se - it has to do with how the technology is being adopted. Regards, AHS __ Arved Sandstrom Sr Software Developer Platform Products Group Halifax RD Office Hummingbird Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/codegen foproperties.xml
arved 02/04/23 15:22:53 Modified:src/codegen Tag: fop-0_20_2-maintain foproperties.xml Log: support for background-image (all renderers) author: Michael Gratton Revision ChangesPath No revision No revision 1.25.2.3 +9 -2 xml-fop/src/codegen/foproperties.xml Index: foproperties.xml === RCS file: /x1/home/cvs/xml-fop/src/codegen/foproperties.xml,v retrieving revision 1.25.2.2 retrieving revision 1.25.2.3 diff -u -r1.25.2.2 -r1.25.2.3 --- foproperties.xml 6 Dec 2001 21:28:21 - 1.25.2.2 +++ foproperties.xml 23 Apr 2002 22:22:52 - 1.25.2.3 @@ -397,13 +397,20 @@ property namebackground-image/name inheritedfalse/inherited -datatypeToBeImplemented/datatype +datatypeString/datatype defaultnone/default /property property namebackground-repeat/name inheritedfalse/inherited -datatypeToBeImplemented/datatype +datatypeEnum/datatype + enumeration + value const=REPEATrepeat/value + value const=REPEAT_Xrepeat-x/value + value const=REPEAT_Yrepeat-y/value + value const=NO_REPEATno-repeat/value + value const=INHERITinherit/value + /enumeration defaultrepeat/default /property property - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo PropertyManager.java
arved 02/04/23 15:23:39
Modified:src/org/apache/fop/fo Tag: fop-0_20_2-maintain
PropertyManager.java
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No revision
No revision
1.7.2.3 +61 -18xml-fop/src/org/apache/fop/fo/PropertyManager.java
Index: PropertyManager.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/PropertyManager.java,v
retrieving revision 1.7.2.2
retrieving revision 1.7.2.3
diff -u -r1.7.2.2 -r1.7.2.3
--- PropertyManager.java 9 Jan 2002 11:32:57 - 1.7.2.2
+++ PropertyManager.java 23 Apr 2002 22:23:39 - 1.7.2.3
@@ -1,5 +1,5 @@
/*
- * $Id: PropertyManager.java,v 1.7.2.2 2002/01/09 11:32:57 keiron Exp $
+ * $Id: PropertyManager.java,v 1.7.2.3 2002/04/23 22:23:39 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -7,27 +7,32 @@
package org.apache.fop.fo;
-import org.apache.fop.layout.FontState;
-import org.apache.fop.layout.FontInfo;
-import org.apache.fop.layout.BorderAndPadding;
-import org.apache.fop.layout.MarginProps;
-import org.apache.fop.layout.BackgroundProps;
-import org.apache.fop.layout.MarginInlineProps;
-import org.apache.fop.layout.AccessibilityProps;
-import org.apache.fop.layout.AuralProps;
-import org.apache.fop.layout.RelativePositionProps;
-import org.apache.fop.layout.AbsolutePositionProps;
+import java.net.MalformedURLException;
+import java.text.FieldPosition;
+import java.text.MessageFormat;
+
+import org.apache.fop.apps.FOPException;
import org.apache.fop.fo.properties.BreakAfter;
import org.apache.fop.fo.properties.BreakBefore;
import org.apache.fop.fo.properties.Constants;
-import org.apache.fop.layout.HyphenationProps;
-import org.apache.fop.apps.FOPException;
-import java.text.MessageFormat;
-import java.text.FieldPosition;
+import org.apache.fop.fo.properties.TextDecoration;
+import org.apache.fop.image.FopImage;
+import org.apache.fop.image.FopImageFactory;
+import org.apache.fop.image.FopImageException;
+import org.apache.fop.layout.AbsolutePositionProps;
+import org.apache.fop.layout.AccessibilityProps;
import org.apache.fop.layout.Area;
+import org.apache.fop.layout.AuralProps;
+import org.apache.fop.layout.BackgroundProps;
+import org.apache.fop.layout.BorderAndPadding;
import org.apache.fop.layout.ColumnArea;
+import org.apache.fop.layout.FontInfo;
+import org.apache.fop.layout.FontState;
+import org.apache.fop.layout.HyphenationProps;
+import org.apache.fop.layout.MarginInlineProps;
+import org.apache.fop.layout.MarginProps;
+import org.apache.fop.layout.RelativePositionProps;
import org.apache.fop.layout.TextState;
-import org.apache.fop.fo.properties.TextDecoration;
public class PropertyManager {
@@ -35,6 +40,7 @@
private FontState fontState = null;
private BorderAndPadding borderAndPadding = null;
private HyphenationProps hyphProps = null;
+private BackgroundProps bgProps = null;
private String[] saLeft;
private String[] saRight;
@@ -212,8 +218,45 @@
}
public BackgroundProps getBackgroundProps() {
-BackgroundProps bp = new BackgroundProps();
-return bp;
+if (bgProps == null) {
+this.bgProps = new BackgroundProps();
+ // bgProps.backAttachment =
this.properties.get(background-attachment).getEnum();
+ bgProps.backColor =
+ this.properties.get(background-color).getColorType();
+
+ String src = this.properties.get(background-image).getString();
+ if (src.equalsIgnoreCase(none)) {
+ bgProps.backImage = null;
+ }
+ else if (src.equalsIgnoreCase(inherit)) {
+ // XXX: implement this
+ bgProps.backImage = null;
+ }
+ else {
+ try {
+ bgProps.backImage = FopImageFactory.Make(src);
+ }
+ catch (MalformedURLException urlex) {
+ bgProps.backImage = null;
+ // XXX: use a logger instead
+ System.out.println(Error creating background image:
+ + urlex.getMessage());
+ }
+ catch (FopImageException imgex) {
+ bgProps.backImage = null;
+ // XXX: use a logger instead
+ System.out.println(Error creating background image:
+ + imgex.getMessage());
+ }
+ }
+
+ bgProps.backRepeat
cvs commit: xml-fop/src/org/apache/fop/fo/flow Block.java BlockContainer.java ListBlock.java Table.java TableBody.java TableCell.java TableColumn.java TableRow.java
arved 02/04/23 15:24:45
Modified:src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
Block.java BlockContainer.java ListBlock.java
Table.java TableBody.java TableCell.java
TableColumn.java TableRow.java
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No revision
No revision
1.41.2.4 +2 -5 xml-fop/src/org/apache/fop/fo/flow/Block.java
Index: Block.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Block.java,v
retrieving revision 1.41.2.3
retrieving revision 1.41.2.4
diff -u -r1.41.2.3 -r1.41.2.4
--- Block.java9 Jan 2002 11:32:57 - 1.41.2.3
+++ Block.java23 Apr 2002 22:24:44 - 1.41.2.4
@@ -1,5 +1,5 @@
/*
- * $Id: Block.java,v 1.41.2.3 2002/01/09 11:32:57 keiron Exp $
+ * $Id: Block.java,v 1.41.2.4 2002/04/23 22:24:44 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -53,7 +53,6 @@
int spaceAfter;
int textIndent;
int keepWithNext;
-ColorType backgroundColor;
int blockWidows;
int blockOrphans;
@@ -154,8 +153,6 @@
this.properties.get(text-indent).getLength().mvalue();
this.keepWithNext =
this.properties.get(keep-with-next).getEnum();
-this.backgroundColor =
-this.properties.get(background-color).getColorType();
this.blockWidows =
this.properties.get(widows).getNumber().intValue();
@@ -245,7 +242,7 @@
blockArea.setParent(area);// BasicLink needs it
blockArea.setPage(area.getPage());
-blockArea.setBackgroundColor(backgroundColor);
+blockArea.setBackground(propMgr.getBackgroundProps());
blockArea.setBorderAndPadding(propMgr.getBorderAndPadding());
blockArea.setHyphenation(propMgr.getHyphenationProps());
blockArea.start();
1.11.2.1 +2 -6 xml-fop/src/org/apache/fop/fo/flow/BlockContainer.java
Index: BlockContainer.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/flow/BlockContainer.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- BlockContainer.java 6 Aug 2001 09:12:59 - 1.11
+++ BlockContainer.java 23 Apr 2002 22:24:44 - 1.11.2.1
@@ -1,5 +1,5 @@
/*
- * $Id: BlockContainer.java,v 1.11 2001/08/06 09:12:59 keiron Exp $
+ * $Id: BlockContainer.java,v 1.11.2.1 2002/04/23 22:24:44 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -21,7 +21,6 @@
public class BlockContainer extends FObj {
-ColorType backgroundColor;
int position;
int top;
@@ -87,9 +86,6 @@
this.marker = 0;
-this.backgroundColor =
-this.properties.get(background-color).getColorType();
-
this.position = this.properties.get(position).getEnum();
this.top = this.properties.get(top).getLength().mvalue();
this.bottom = this.properties.get(bottom).getLength().mvalue();
@@ -119,7 +115,7 @@
position);
areaContainer.setPage(area.getPage());
-areaContainer.setBackgroundColor(backgroundColor);
+areaContainer.setBackground(propMgr.getBackgroundProps());
areaContainer.setBorderAndPadding(propMgr.getBorderAndPadding());
areaContainer.start();
1.21.2.1 +2 -5 xml-fop/src/org/apache/fop/fo/flow/ListBlock.java
Index: ListBlock.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/flow/ListBlock.java,v
retrieving revision 1.21
retrieving revision 1.21.2.1
diff -u -r1.21 -r1.21.2.1
--- ListBlock.java20 Aug 2001 11:19:23 - 1.21
+++ ListBlock.java23 Apr 2002 22:24:44 - 1.21.2.1
@@ -1,5 +1,5 @@
/*
- * $Id: ListBlock.java,v 1.21 2001/08/20 11:19:23 keiron Exp $
+ * $Id: ListBlock.java,v 1.21.2.1 2002/04/23 22:24:44 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -43,7 +43,6 @@
int spaceBefore;
int spaceAfter;
int spaceBetweenListRows = 0
cvs commit: xml-fop/src/org/apache/fop/fo/pagination RegionAfter.java RegionBefore.java RegionBody.java RegionEnd.java RegionStart.java
arved 02/04/23 15:25:25
Modified:src/org/apache/fop/fo/pagination Tag: fop-0_20_2-maintain
RegionAfter.java RegionBefore.java RegionBody.java
RegionEnd.java RegionStart.java
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No revision
No revision
1.9.2.1 +7 -5 xml-fop/src/org/apache/fop/fo/pagination/RegionAfter.java
Index: RegionAfter.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/RegionAfter.java,v
retrieving revision 1.9
retrieving revision 1.9.2.1
diff -u -r1.9 -r1.9.2.1
--- RegionAfter.java 30 Jul 2001 20:29:25 - 1.9
+++ RegionAfter.java 23 Apr 2002 22:25:25 - 1.9.2.1
@@ -1,5 +1,5 @@
/*
- * $Id: RegionAfter.java,v 1.9 2001/07/30 20:29:25 tore Exp $
+ * $Id: RegionAfter.java,v 1.9.2.1 2002/04/23 22:25:25 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -57,10 +57,12 @@
// this.properties.get(reference-orientation);
// this.properties.get(writing-mode);
-return new RegionArea(allocationRectangleXPosition,
- allocationRectangleYPosition
- - allocationRectangleHeight + extent,
- allocationRectangleWidth, extent);
+RegionArea area = new RegionArea(allocationRectangleXPosition,
+ allocationRectangleYPosition
+ - allocationRectangleHeight + extent,
+ allocationRectangleWidth, extent);
+ area.setBackground(bProps);
+ return area;
}
1.9.2.1 +6 -4 xml-fop/src/org/apache/fop/fo/pagination/RegionBefore.java
Index: RegionBefore.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/RegionBefore.java,v
retrieving revision 1.9
retrieving revision 1.9.2.1
diff -u -r1.9 -r1.9.2.1
--- RegionBefore.java 30 Jul 2001 20:29:25 - 1.9
+++ RegionBefore.java 23 Apr 2002 22:25:25 - 1.9.2.1
@@ -1,5 +1,5 @@
/*
- * $Id: RegionBefore.java,v 1.9 2001/07/30 20:29:25 tore Exp $
+ * $Id: RegionBefore.java,v 1.9.2.1 2002/04/23 22:25:25 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -58,9 +58,11 @@
// this.properties.get(reference-orientation);
// this.properties.get(writing-mode);
-return new RegionArea(allocationRectangleXPosition,
- allocationRectangleYPosition,
- allocationRectangleWidth, extent);
+RegionArea area = new RegionArea(allocationRectangleXPosition,
+ allocationRectangleYPosition,
+ allocationRectangleWidth, extent);
+ area.setBackground(bProps);
+ return area;
}
1.11.2.1 +3 -9 xml-fop/src/org/apache/fop/fo/pagination/RegionBody.java
Index: RegionBody.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/RegionBody.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- RegionBody.java 20 Aug 2001 11:19:24 - 1.11
+++ RegionBody.java 23 Apr 2002 22:25:25 - 1.11.2.1
@@ -1,5 +1,5 @@
/*
- * $Id: RegionBody.java,v 1.11 2001/08/20 11:19:24 keiron Exp $
+ * $Id: RegionBody.java,v 1.11.2.1 2002/04/23 22:25:25 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -11,7 +11,6 @@
import org.apache.fop.fo.FObj;
import org.apache.fop.fo.PropertyList;
import org.apache.fop.fo.properties.Overflow;
-import org.apache.fop.datatypes.ColorType;
import org.apache.fop.apps.FOPException;
import org.apache.fop.layout.RegionArea;
import org.apache.fop.layout.BodyRegionArea;
@@ -36,8 +35,6 @@
public static final String REGION_CLASS = body;
-ColorType backgroundColor;
-
protected RegionBody(FObj parent,
PropertyList propertyList) throws FOPException {
super(parent, propertyList);
@@ -61,9 +58,6 @@
// this.properties.get(reference-orientation
cvs commit: xml-fop/src/org/apache/fop/render/txt TXTRenderer.java
arved 02/04/23 15:33:40
Modified:src/org/apache/fop/render/awt Tag: fop-0_20_2-maintain
AWTRenderer.java
src/org/apache/fop/render/mif Tag: fop-0_20_2-maintain
MIFRenderer.java
src/org/apache/fop/render/pcl Tag: fop-0_20_2-maintain
PCLRenderer.java
src/org/apache/fop/render/pdf Tag: fop-0_20_2-maintain
PDFRenderer.java
src/org/apache/fop/render/ps Tag: fop-0_20_2-maintain
PSRenderer.java
src/org/apache/fop/render/svg Tag: fop-0_20_2-maintain
SVGRenderer.java
src/org/apache/fop/render/txt Tag: fop-0_20_2-maintain
TXTRenderer.java
Log:
support for background-image (all renderers)\nauthor: Michael Gratton
Revision ChangesPath
No revision
No revision
1.38.2.2 +41 -8 xml-fop/src/org/apache/fop/render/awt/AWTRenderer.java
Index: AWTRenderer.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/render/awt/AWTRenderer.java,v
retrieving revision 1.38.2.1
retrieving revision 1.38.2.2
diff -u -r1.38.2.1 -r1.38.2.2
--- AWTRenderer.java 11 Jan 2002 08:45:06 - 1.38.2.1
+++ AWTRenderer.java 23 Apr 2002 22:33:39 - 1.38.2.2
@@ -1,5 +1,5 @@
/*
- * $Id: AWTRenderer.java,v 1.38.2.1 2002/01/11 08:45:06 keiron Exp $
+ * $Id: AWTRenderer.java,v 1.38.2.2 2002/04/23 22:33:39 arved Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -412,19 +412,13 @@
h = area.getContentHeight();
int ry = this.currentYPosition;
-ColorType bg = area.getBackgroundColor();
rx = rx - area.getPaddingLeft();
ry = ry + area.getPaddingTop();
w = w + area.getPaddingLeft() + area.getPaddingRight();
h = h + area.getPaddingTop() + area.getPaddingBottom();
-// I'm not sure I should have to check for bg being null
-// but I do
-if ((bg != null) (bg.alpha() == 0)) {
-this.addRect(rx, ry, w, -h, bg.red(), bg.green(), bg.blue(),
- bg.red(), bg.green(), bg.blue());
-}
+ doBackground(area, rx, ry, w, h);
rx = rx - area.getBorderLeftWidth();
ry = ry + area.getBorderTopWidth();
@@ -486,6 +480,45 @@
this.currentYPosition -= d;
}
+/**
+ * Renders an image, scaling it to the given width and height.
+ * If the scaled width and height is the same intrinsic size
+ * of the image, the image is not scaled.
+ *
+ * @param x the x position of left edge in millipoints
+ * @param y the y position of top edge in millipoints
+ * @param w the width in millipoints
+ * @param h the height in millipoints
+ * @param image the image to be rendered
+ * @param fs the font state to use when rendering text
+ * in non-bitmapped images.
+ */
+protected void drawImageScaled(int x, int y, int w, int h,
+FopImage image,
+FontState fs) {
+ // XXX: implement this
+}
+
+/**
+ * Renders an image, clipping it as specified.
+ *
+ * @param x the x position of left edge in millipoints.
+ * @param y the y position of top edge in millipoints.
+ * @param clipX the left edge of the clip in millipoints
+ * @param clipY the top edge of the clip in millipoints
+ * @param clipW the clip width in millipoints
+ * @param clipH the clip height in millipoints
+ * @param fill the image to be rendered
+ * @param fs the font state to use when rendering text
+ * in non-bitmapped images.
+ */
+protected void drawImageClipped(int x, int y,
+ int clipX, int clipY,
+ int clipW, int clipH,
+ FopImage image,
+ FontState fs) {
+ // XXX: implement this
+}
// correct integer roundoff(aml/rlc)
No revision
No revision
1.11.2.1 +42 -13xml-fop/src/org/apache/fop/render/mif/MIFRenderer.java
Index: MIFRenderer.java
===
RCS file: /x1/home/cvs/xml-fop/src/org/apache/fop/render/mif/MIFRenderer.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- MIFRenderer.java 18 Sep 2001 13:06:07 - 1.11
RE: Aids to distributed design
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 23, 2002 8:18 AM To: fop-dev Subject: Aids to distributed design [ SNIP ] 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? There is apparently some stuff out there, based on a simple Google search (all hail Google). There is http://hem.fyristorg.com/matben/, which looks pretty good but it all depends on how well it works; there is also a Mozilla spin-off (http://jabberzilla.mozdev.org/releases/). These mostly seem to be based on Jabber. It wouldn't take much to do up a JMS solution using an open-source JMS broker and some applets (I have a colleague who knocked out something pretty similar as an inhouse experiment in a couple of days). Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: inital background-image patch
Hi, Dimitri With respect to full-page backgrounds this is something that has come up before. fo:simple-page-master does not take background properties so you have to work with regions or below, which do. Let's say that you don't have any outer regions - you could have a region-body with zero-margins, and a background would fill the page. Because regions have zero width borders and padding unfortunately the content rectangle of the region reference area would fill the page also, but you can use start and end indents, and space-before and space-after, to constrain your content as desired. If you had outer regions they could overlap, and your spaces and indents for the region-body could account for that, too; with a background-color of transparent on the outer regions you'd be all set. I am not recommending this because I personally think it goes a bit against the spirit of the spec, but as near as I can tell it's all perfectly legal. I seem to recall from last year that we had convinced ourselves that one could not render backgrounds into regions, but my reading of the spec now doesn't show me that at all. Maybe others can add their comments. 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. Regards, Arved Sandstrom -Original Message- From: Softgui [mailto:[EMAIL PROTECTED]] Sent: April 22, 2002 5:42 AM To: [EMAIL PROTECTED] Subject: Re: inital background-image patch I've tryed this with PDF and it seems to work well, but I coudn't find a way to have a complete page background (with no resize). The back ground is only under the text blocks. Have you, or some one else have some background image samples ? If not I can work on it if you want (like a new example directory). Thanks, Dimitri BAELI - Message d'origine - De : Michael Gratton [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : lundi 22 avril 2002 05:11 Objet : Re: inital background-image patch Arved Sandstrom wrote: I will definitely check it out. Thanks Arved. I've put v0.02 of the patch up. This fixes one small bug when tiling background images, but more importantly I've removed the changes to fix addRectFoo() wanting a negative height. This simpilifies the patch and greatly reduces the scope of the changes. Let me know what you think. I'm going to start on getting the other renderers working next. http://web.vee.net/fop/background-image_0.02.patch http://web.vee.net/fop/fop-background-image-0.02-bin.tar.gz http://web.vee.net/fop/fop-background-image-0.02-bin.zip Cheers. Mike, -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 - 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: inital background-image patch
-Original Message- From: Michael Gratton [mailto:[EMAIL PROTECTED]] Sent: April 22, 2002 11:11 PM To: [EMAIL PROTECTED] Subject: Re: inital background-image patch Arved Sandstrom wrote: I seem to recall from last year that we had convinced ourselves that one could not render backgrounds into regions, but my reading of the spec now doesn't show me that at all. Maybe others can add their comments. I don't see why not, given the spec lists the Common border, padding, and background properties as being allowed, and doesn't forbid use of the background properties in the text of the region areas. Anyway, the next version of the background-image patch should have backgrounds for the region areas working. Mike. Yeah, I rechecked the prose carefully and I didn't spot anything either. Slight segue: I was up at the cottage this weekend opening up, and lots of evenings this week are hosed also, but tomorrow evening is open, so I'll quickly apply your patch, build, run it, and commit it if that all works out, which I don't doubt. I don't think I noticed anyone else apply it yet - correct me if I am wrong. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: inital background-image patch
I will definitely check it out. Regards, AHS -Original Message- From: Michael Gratton [mailto:[EMAIL PROTECTED]] Sent: April 19, 2002 1:02 AM To: [EMAIL PROTECTED] Subject: inital background-image patch Guys, An initial maintenance-branch patch for background-image and background-repeat property support can be found at: http://web.vee.net/fop/background-image_0.01.patch This patch is *not* ready to get comitted to the repository, rather I'm posting it to a) get some help testing it, b) get feedback about the nature and scope of the changes I've made. So please, have a look at it, try it out, and send me as much feedback as possible, especially on: - The API changes to AbstractRenderer. - Changing addRectFoo() to only ever expect +ve heights. - Seeing if the MIF and TXT renderers still work as advertised (but without bg image support). To support background images, the following has changed: - Implemented the background-image and background-repeat properties. - PropertyManager resolves the bg image source to a FopImage when first retreiving an instance of BackgroundProps. - Areas now store an instance of BackgroundProps rather than just the background color. - AbstractRenderer has a concrete doBackground() method, and abstract drawImageFoo() methods to support doBackground(), renderImageArea() and possibly others. - PDFRenderer and PrintRenderer have been modified to use doBackground() and provide concrete implementations of the drawImageFoo() methods. As a direct result: - PDFRenderer.renderImageArea() has been generalized and moved into AbstractRenderer. - Start of support for working region-foo backgrounds has been added - The addRectFoo() methods should now expect only +ve heights Stuff that isn't working: - All renderers other than PDFRenderer, and possibly the MIF renderer and TXTRenderer. - Image cropping, so on a tiled background, the last row and column of images are scaled rather than cropped if the width/height if the content area isn't an exact multiple of the image's width/height. Binaries for testing can be found at: http://web.vee.net/fop/fop-background-image-0.01-bin.tar.gz http://web.vee.net/fop/fop-background-image-0.01-bin.zip Please *do not* use this binary in a production system. Thanks (especially for reading this far ;), Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cvs access
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. 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. Arved -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 19, 2002 10:01 PM To: fop-dev Subject: cvs access 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Vote] New committer: Jeremias Maerki
Agreed, definitely. +1. I think we want to be generous when proposing and voting on new committers. The main thing is staying power - I can say this even though my efforts have been sparse as of late - and all three nominated individuals have demonstrated plenty of it, to my mind. AHS -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: April 13, 2002 3:04 PM To: [EMAIL PROTECTED] Subject: [Vote] New committer: Jeremias Maerki Hi all, 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. Here is my vote: +1 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: AW: Multithreading FOP ?
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 13, 2002 11:15 PM To: [EMAIL PROTECTED] Subject: Re: AW: Multithreading FOP ? [ SNIP ] 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? Being distributed is the major factor. This is also true for servlets that are J2EE-compatible. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Vote] New committers: Peter West, Joerg Pietschmann?
Absolutely and wholeheartedly +1. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 11, 2002 7:16 AM To: [EMAIL PROTECTED] Subject: [Vote] New committers: Peter West, Joerg Pietschmann? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Status
This is still accurate as far as I am concerned, although I have not done much yet. However I have to look at images anyway with respect to my other project so it will definitely happen and happen soon. I am also transitioning my FOP development setup from Linux over to Win2K so I can get more productive. I just need to get my SSH set up (new password, basically) and I'll be ready to develop on FOP in short order. :-) Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 10, 2002 6:33 AM To: [EMAIL PROTECTED] Subject: FOP Status Fop Status - April 10 The layout process remains the critical path to the further development of properties and elements. Many other areas are getting attention, such as configuration and documentation. Development --- done: understanding docs - Cyril, Peter, Keiron, Karen added portuguese hyphenation - Paulo Soares implemented simple vertical alignment for line area - Keiron working on (if any details are incorrect or someone feels left out give us a yell :) image handling - Arved line area layout, understanding - Keiron avalon/configuration - Nicola properties/build/configuration/design - Peter FAQ - Joerg, Alex features/limitations list - Chuck Paussa and others documentation - Cyril rtf renderer - Bertrand PDF Forms extension - Hansuli Anderegg Things to do: Apart from the things that are being done there are a number of areas we can work on to create a better FOP. In general we have: Get a solid understanding and basis for the layout process. structure renderer simple examples testing Maintenance releases done: russian for AWTViewer - Alex V. Alishevskikh Updated Ant - Christian Use ant style task for build - Christian A maintenance release will be required. This will be after batik1.5 is released. working on: maintenance updates - Christian - 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: implementing background-image (bug 5180)
Hi, Michael You picked a good one to get your feet wet with. No, I wouldn't say that there is anything about this that is going to trip you up, or implementation quirks that you wouldn't get from existing code (I assume we are talking maintenance branch?). One thing that you might end up doing, being unfamiliar with FOP source, is to do way more for this property than you need. The background properties are pure rendering traits, and with the exception of background-position-horizontal and background-position-vertical, require absolutely no more work at any stage of layout other than to ensure that appropriate traits (instance variables) are set on the affected areas that are eventually passed to the renderers. Almost all of the real work is in the renderer stage. Regards, Arved Sandstrom -Original Message- From: Michael Gratton [mailto:[EMAIL PROTECTED]] Sent: April 7, 2002 10:05 PM To: [EMAIL PROTECTED] Subject: implementing background-image (bug 5180) Guys, I need to be able to use the background-image property, which is not yet implemented http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5180. Is anyone working on this at the moment? If not, I'm happy to make an attempt at it. Is there anything I should know about implementing properties in FOP, or this one in general, that I wouldn't pick up from looking at the existing code? Thanks, Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 - 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: Some comments on the build system
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.
Regards,
Arved
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: April 3, 2002 12:23 PM
To: fop-dev
Subject: Some comments on the build system
Fops,
I would like to see the build system overhauled. The overall objectives
of the overhaul would be to simplify the build process and decrease
barriers to entry for would-be developers. The tactical objectives
would be to eliminate XSL from the build, and to generate the classes
directly from the source tree. The advantages of this approach are, I
think, obvious. For a developer using an IDE/JDE, the source tree
associated with the classes whose behaviour is being observed would be
the same source tree to which changes are being made, and the same
source tree from which commits would be made. Eliminating XSL, and
expressing the system entirely in Java means that, as far as development
is concerned, what you see is what you get. There are no invisible
shenanigans going on behind the build.
I have not gone over the XSL with a fine-toothed comb, but what I have
seen is enough to be able to give the flavour of the argument.
Basically, if you feel the need to generate Java from a combination of
XML and XSL, you should make your Java look more like your XML, and less
like the output from your XSL. The neat data characteristics of the XML
can and should be expressed more or less directly in Java.
Font generation is simple to translate into a static reference HashMap
from names to codepoints, set up with a static{} block, and some further
static{}s to set up the width arrays.
Properties are a fascinating topic. To me, the fact that Properties
virtually demand some kind of code generation is proof enough that the
approach is wrong. But more of that another time. Let's say that you
do need some help to set these things up. How many times do you need to
do it? Isn't once enough? The majority of the class files having been
set up, what varies?
Create the base files, and check them in to CVS. Then put the XML and
XSL aside as a once-useful historical oddity. Unimplemented properties
RE: JAXP / upgrade to xerces2
No objections, so a +1 from me. While we're at it I think we should take the opportunity to change the fop.jar manifest Class-Path (see earlier posts on this subject), so that none of the required JARs are expected to be in a lib/ directory. fop.jar can get built into the same directory that all the other JARs are already in; this is how it will normally get used anyhow. I already posted about this once and there were no objections. If there is again no objection I am going to go ahead and do this. Regards, AHS -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: March 25, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: JAXP / upgrade to xerces2 Hi all, I finally have Joerg's JAXP patch committed (well most part of it). FOP should now *run* with any JAXP1.1 compliant parser/transformer. I've succesfully tested it with Saxon 6.5.1 (which includes Aelfred) and JDK1.4 (which includes Crimson/Xalan). Still needs to be done: - build process (replace fop's xslt-task with ant's style-task as already done in the main branch) - hypenation generation (Joerg mentioned some problems) I think this might be a good opportunity to upgrade FOP to xerces2 (and xalan 2.3.1). The only drawback is probably that xerces ships as two jars (xmlParserAPIs.jar and xercesImpl.jar). Any Comments? Christian - 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: [Fwd: Numbering lines]
Hi, Patrick Yes, this would be useful. All you can do now is if you know the lines ahead of time; then you can use XSLT xsl:number if your source XML permits. But for what you are talking about, no, XSL formatting does not have a way of doing it, although one can certainly imagine an extension that extends layout for each LineArea. Regards, AHS -Original Message- From: Patrick Andries [mailto:[EMAIL PROTECTED]] Sent: March 20, 2002 7:47 PM To: [EMAIL PROTECTED] Subject: [Fwd: Numbering lines] I sent the message to fop-user, no one answered. If this is not possible (probable), would the extension be simple (useful in legislative text). Message d'origine Objet: Numbering lines Is it possible to dynamically number lines in FO ? P. Andries - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: development status
-Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: March 19, 2002 11:48 AM To: [EMAIL PROTECTED] Subject: Re: development status From: Keiron Liddle [EMAIL PROTECTED] Retrieve Markers? IMHO yes, since you can make a forward reference with it. -Original Message- The section on retrieve-marker is not well written, but I would assert with a high degree of confidence that for any retrieve-marker, the only qualifying markers have already been seen. Supporting analysis: Spec Statement 1 - The term 'containing page' is used here to mean the page that contains the first area generated or returned by the children of the retrieved fo:marker. Spec Statement 2 - [ qualifying ] areas do not have a position in the hierarchy if they are within pages that follow the containing page. Statement 1 tells me that the page containing the fo:retrieve-marker is the containing page. Statement 2 tells me that markers, which otherwise qualify on the basis of class-name and retrieve-boundary, are ruled out. This is pretty unambiguous, although other parts of the relevant discussion are not. I am open to counter-arguments. The reason I am open to counter-arguments is I read stuff like this, for example: A) If the value of the retrieve-position property is last-starting-within-page, then the last qualifying area in the containing page whose is-first trait has a value of true is better than any other area. If there is no such area, then the last qualifying area in the containing page is better than any other area. AND B1) Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. When comparing two areas to determine which one is better, the terms first and last refer to the preorder traversal order of the area tree. COUPLED WITH B2) A qualifying area within a page is better than any qualifying area within a preceding page. and my brain starts to implode. What does this mean? That _if_ there are NO areas on the containing page that have is-first = true, and in fact, there are no qualifying areas on the containing page at all, then Rule A kicks in and a qualifying area on page 11 is better than a qualifying area on page 18? In fact the entire question of what qualifying areas should be selected of nothing is found on the containing page is up in the air - apparently one always selects the first qualifying area (pre-order traversal of the area tree) subject to class-name and retrieve-boundary. Better to select nothing at all. Anyway, that's my little rant on markers. I raised the issue last year but never got an answer. But in terms of forward references fortunately the spec is very clear. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Image Handling Question
Hi, Keiron OK, I'll buy all of this. I need to get used to the idea that we are actually doing viewports. :-) That changes things. :-) With viewports being used then the ImageArea becomes a relatively unimportant thing. Except right at the beginning, where odds are pretty good that the author will set auto for block- and inline-progression-dimension (that is, not set those at all, nor 'height' and 'width'), and therefore in conjunction with 'content-width', 'content-height', and scaling we'll have to figure out the content size so the _viewport_ can get this for itself. But afterwards nobody should care about the image itself except for the renderer. And in the case that BPD and IPD are both explicitly set on the viewport then layout will _never_ care about the actual image. So I don't disagree, although I'd get pedantic and point out that, yes, we're setting _a_ size on the viewport, but that is not necessarily the size of the image. But layout doesn't care - it only cares about the size of the viewport. Using the URL as a cache key clears other things up, too. Thanks. Is it safe to assume that when we refer to the image being in cache, and being retrieved from cache with the URL, etc etc, that _this_ image is the FopAbstractImage or an advanced version of same? Regards, Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: March 18, 2002 4:22 AM To: [EMAIL PROTECTED] Subject: Re: Image Handling Question Hi Arved, There are a couple of reasons that it only has a URL. If the page is going to be serialized we don't want to serialize an image. There is no advantage to having a reference to the image and it would make it harder to keep track of references for caching. The URL is used as a key to get the image from the cache. The only problem with this is if someone decides to use two syntactily different URL's for the same image, which I am guessing is rare. As for the size, since the image is inside a viewport I was thinking of setting the size and position in the viewport. There are other objects that can be in the viewport that need the same things. So in the FOTree it only grabs the image (using the URL) if the size of the image is needed. The image is then in the cache with the URL as the key. When the renderer comes to render the image it grabs the image again and draws it. In the case of the PDF Renderer it no longer needs the original image in the cache so it releases the image. The image is then available as a PDF Object. Keiron. On 2002.03.17 18:38 Arved Sandstrom wrote: Keiron or Karen, I have a quick question. This is mostly because I am unfamiliar with the code. As it stands right now org.apache.fop.area.inline.ImageArea does not look like something that the layout process can use; it also doesn't look like something that the renderer can use because it supplies only a URL reference, not any extra information as to what changes (e.g. scaling) may have taken place. So is it the case that org.apache.fop.image.AbstractFopImage (or something like it) is the primary object to be used in layout? And I'm thinking that if this is the case, that the ImageArea class should not have a reference to a URL, but rather to the AbstractFopImage. Am I missing something here? I am going to continue on with research - I have plenty of serious reading and code review ahead of me, I can see. I wanted to ask about _this_ to maybe speed things up with image handling. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
