Re: Sources for layout.jpg

2005-03-11 Thread Glen Mazza
--- The Web Maestro [EMAIL PROTECTED] wrote: Does anyone have any objections to my making these files LIVE on the FOP site (and replacing the current document.jpg image on the home page)? None whatsoever, but I'm going to act like I do in order to get something I want in exchange... No

Re: master-reference '' for fo:page-sequence matches no simple-page-master or page-sequence-master

2005-03-10 Thread Glen Mazza
Quite happy to. Done. Glen --- Simon Pepping [EMAIL PROTECTED] wrote: Glen, On Wed, Mar 09, 2005 at 11:34:29AM -0800, Glen Mazza wrote: The property on fo:conditional-page-master-reference should be master-reference, not master-name [1]. I had this problem too the other day. Can

Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Otherwise, I'd rather use ImageIO even if it's only available in JDKs =1.4. I thought FOP should be 1.3 compilant [3]? So how do we go around that? That's right. But nothing stops us from providing additional code that's JDK 1.4

Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Ah, there's the catch. Yes, CCITT4 is particularly interesting which is not supported by the code in Batik. But still, I think we don't have to I don't think we have to support everything under JDK 1.3. Or anything, for that matter. 1.3 users

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

2005-03-09 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: RFC 2045 [1] says this: (1) Private values (starting with X-) may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or

Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-08 Thread Glen Mazza
Team, Oleg's TIFF Renderer is under the Mozilla license[1], not the Apache one (also apparently some of the code is from Sun?). Is the former compatible with the latter? If not, I would like Oleg to switch the license on it before we proceed further in putting it into FOP. Renaud--thanks for

Re: Integration of TIFFRenderer in FOP

2005-03-08 Thread Glen Mazza
Yeah, Peter makes me want to do that sometimes myself... ;) Glen --- vivek gupta [EMAIL PROTECTED] wrote: How to leave this group. Please help me to unsubscribe. --- Peter B. West [EMAIL PROTECTED] wrote: Renaud Richardet wrote: Oleg, I'm currently working on the

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

2005-03-08 Thread Glen Mazza
The application/awt MIME type doesn't exist. I think Jeremias wanted this to be null instead for output types that lack a MIME type, correct? Thanks, Glen --- [EMAIL PROTECTED] wrote: +/** The MIME type for AWT-Rendering */ public static final String MIME_TYPE =

Re: FOP at ApacheCon Europe 2005?

2005-03-07 Thread Glen Mazza
Fantastic! I hope to be able to do the same someday. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: FYI, I've just given myself a shove, followed Bertrand's suggestion and submitted a session proposal for ApacheCon. I feel that our project should be present there. I was also thinking

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

2005-03-03 Thread Glen Mazza
Happy to see how you have reprioritized your efforts over the past two months [1], and much, much for the better. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I very much hope so. But it becomes more and more apparent that this will be the greatest challenge in my programmer's life.

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
--- Chris Bowditch [EMAIL PROTECTED] wrote: As for the plan to implement a new page-breaking mechanism: I've got to do it now. :-) I'm sorry if this may put some pressure on some of you. I'm also not sure if I'm fit already to tackle it, but I've got to do it anyway. Since I don't

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
into account. On 02.03.2005 13:16:42 Glen Mazza wrote: --- Chris Bowditch [EMAIL PROTECTED] wrote: As for the plan to implement a new page-breaking mechanism: I've got to do it now. :-) I'm sorry if this may put some pressure on some of you. I'm also not sure if I'm

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
/PageLayout On 02.03.2005 14:48:17 Glen Mazza wrote: Just a sanity check here, the XSL specification seems to suggest always the first-fit strategy for page breaking *except* where keeps are explicitly specified. Am I correct here? And, if so, is what you're planning going to result

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
of backtracking. But as Simon suggested, this seems to be a poor approach. Keeps and breaks are only part of what a page breaking algorithm has to deal with. See [3]. [3] http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures On 02.03.2005 16:44:17 Glen Mazza wrote: I'm

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java

2005-03-02 Thread Glen Mazza
Thanks Simon. Glen --- [EMAIL PROTECTED] wrote: spepping2005/03/02 13:03:25 Modified:src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java Log: Corrected a validation problem. Made TableFooter use TableBody's validation.

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-03-01 Thread Glen Mazza
OH!!! lightBulb state=on wattage=25/ Yes, you're right, Chris--now I see the issue. I implemented validation for about 80% of the FOs, but 80% is not 100%. fo:table-body never had any validation implemented, hence the NPE's that were occurring. Sorry, Jeremias, I thought you had just

remove build.bat and build.sh?

2005-02-26 Thread Glen Mazza
Team, Build.bat and build.sh just call ant internally today (and tell them to get Ant if it is not available on their machine)--I would like to move these instructions for how to download activate Ant to our README file instead, and remove these two files. (The check for JAVA_HOME is already

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-25 Thread Glen Mazza
Jeremias, My veto still stands, along with the seven technical reasons given for it. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: On 25.02.2005 07:21:25 Glen Mazza wrote: snip/ For the moment I'm not going to answer the veto itself. Your veto makes this situation a one against

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-25 Thread Glen Mazza
Simon, Thanks for reading and responding to my concerns. I appreciate it. Your endorsement of this change is sufficient for me--I am withdrawing my veto. Regards, Glen --- Simon Pepping [EMAIL PROTECTED] wrote: On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza wrote: Jeremias, I'm

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-24 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: 2. Empty table-bodies make no sense but it makes life easier for stylesheet writers not to have to work around them. I don't see the benefits. In XSLT, one does a test to see if there is data in the source XML that would constitute a

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-24 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I have nothing more to say about this. I want to spend my time on more productive things now. Jeremias, I'm going to veto (-1) your change. I would like the content model restored to the XSL standard and the FONode.removeNode() method removed.

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-23 Thread Glen Mazza
Jeremias, This should not be done. If someone has a problem with it--and I've never heard a complaint--they can send an email to xsl-editors, for them to adjust the content model for fo:table accordingly. (If they don't, they don't.) Note that the editors are very reasonable about this--for

Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-23 Thread Glen Mazza
--- The Web Maestro [EMAIL PROTECTED] wrote: One thing I know for certain, is that it would be great if we could all get together for a beer (root beer or ginger ale is acceptable for those trying to cut down!) I know...sad thing is, you're the closest committer to me and California is

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-23 Thread Glen Mazza
--- Glen Mazza [EMAIL PROTECTED] wrote: Jeremias, This should not be done. If someone has a problem with it--and I've never heard a complaint--they can send an email to xsl-editors, for them to adjust the content model for fo:table accordingly. (If they don't, they don't

Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Now that we've got someone who will work on the AWT Renderer I'd like to know if someone is against renaming the AWT Renderer to Java2D Renderer. AWT Renderer has a rich history within FOP, it's a popular renderer, and I have not heard of any

Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: A veto would have been easier. :-) I would simply have stopped and said: Sigh. Again. Ok, next task. Yes, but the change proposed simply doesn't rise to the level of a veto. Would it be more interesting/agreeable if we would leave the

Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Deal. It seems like we want the same things but didn't understand each other. I hope we do now. I've documented all this in a Wiki page: http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D Looks good! Now whether you wish to do this before

Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Glen Mazza
Richardet wrote: Glen Mazza [EMAIL PROTECTED] wrote: Looks good! Now whether you wish to do this before or after Renaud moves the logic over is up to you two. There's advantages/disadvantages to either method. yes, that looks good! Jeremias, if it's ok for the team, i would

Re: Error in computation of inline progression dimension ?

2005-02-16 Thread Glen Mazza
--- Glen Mazza [EMAIL PROTECTED] wrote: This IMO is the fatal flaw in your logic in your previous email. You determined fo:s-p-m and fo:r-b to be type (1) FO's, and hence used the wrong equations in 5.3.2 to determine calculated values for them. They are type (3) FO's, and hence the first

Re: Error in computation of inline progression dimension ?

2005-02-16 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: It doesn't really matter if the FOs generate reference areas or not, the Well, the Recommendation declares which of the three types each FO belongs to, in the Areas section in each FO definition. It is a static answer that holds for all FO's of a

Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, this results (corresponding properties) in a

Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Glen Mazza
, I was probably not 100% correct in my explanation though my interpretation still stands. On 15.02.2005 18:02:14 Glen Mazza wrote: Oh--5.3.2 says: There are two more properties, end-indent and start-indent (block-level formatting objects) which correspond to the various absolute

Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Glen Mazza
Jeremias, I am wrong here. This phrase in 5.3.2: If the corresponding absolute margin property is specified on the formatting object... Clearly means that margin *is* a CP, and hence is a CP with start-indent/end-indent as appropriate. Forget that argument--never mind, and I'm sorry that you

Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, (margin-left and margin-right of 50pt each on

Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Glen Mazza
On second thought, Jeremias, instead of arguing this, why don't we just compromise at 75pt. margins? ;) Glen --- Glen Mazza [EMAIL PROTECTED] wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent

Re: representative example needed [was in fop-user]

2005-02-14 Thread Glen Mazza
--- Vincent Hennebert [EMAIL PROTECTED] wrote: You would be most welcome here. I really would be glad to help. Sadly I don't have much time to devote to Fop. I've begun to read the XSL spec and dive into Fop code. I'll still need some time before being able to provide patches. Hope

Re: representative example needed [was in fop-user]

2005-02-13 Thread Glen Mazza
Hello Vincent! --- Vincent Hennebert [EMAIL PROTECTED] wrote: [Web Maestro Clay] It would be *great* if some enterprising and generous developer could spend the time to generate FOP-based XSL-FO documents from the XML, XSLT and XPath specs. In fact, that would be a useful tool for

Re: need to update team page

2005-02-13 Thread Glen Mazza
Thanks for updating the site, and also thanks for teaching us how to fish here. I will do this next time I need an update to occur. Glen --- The Web Maestro [EMAIL PROTECTED] wrote: On Feb 11, 2005, at 12:30 PM, Glen Mazza wrote: Clay, I have a favor to ask--when you have the chance

Re: testcases

2005-02-12 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Thanks, Simon. And fop-devs, also note that you are allowed (and encouraged) to correct, modify, improve and add test cases yourself. :-) Can we remove some too?!? ;) Glen

need to update team page

2005-02-11 Thread Glen Mazza
Clay, I have a favor to ask--when you have the chance, would you please republish the FOP team page with my recent changes? Much appreciated! Thanks, Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2005-02-06 Thread Glen Mazza
I just took care of it--you may need to refresh PSLM in the marker patch though as I did some minor changes in that class as well. BTW, I'd like to remove String getCurrentPageNumber(); from the LayoutManager interface and replace it with PageSequence getCurrentPageSequence(). The latter offers

Re: Markers added to the wrong page

2005-02-06 Thread Glen Mazza
OK...I see its purpose now. But please put in a descriptive comment for isBogus() in AbstractLayoutManager so others down the road understand what it means and what it is for. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: Glen, no, I'm afraid the isBogus() method is necessary because

Re: Markers added to the wrong page

2005-02-05 Thread Glen Mazza
Jeremias, I don't see the need for the bBogus variable/isBogus() method, because in the three or four places where the value of this variable is actually *being used*, it is just set to : bBogus = !bp1.generatesAreas(); So it appears you can just rely on !bp1.generatesAreas() in these places

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2005-02-04 Thread Glen Mazza
Jeremias, We are using this pageCount statistic only at endDocument() in ATH, i.e., when the document is complete. Any problem with us just relying on the rootFObj.getRunningPageNumberCounter() in endDocument() instead of this page-by-page callback (i.e., get rid of pageCount in ATH)? I would

Re: Markers added to the wrong page

2005-02-03 Thread Glen Mazza
Can't add much here, but I do remember noticing the bogus areas being created when I was trying to fix spacing about a year ago. And, yes, I do agree it would be better if our algorithms did not need them to be created. Thanks, Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I've got a

Re: (housekeeping) need Compare class, TestConverter.getLogger()/.setLogger()?

2005-01-30 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: On 22.01.2005 18:18:06 Glen Mazza wrote: Hello--three questions: Is anyone using the get/setLogger() methods within TestConverter? (It is coded to use a SimpleLog by default.) I think these two methods are holdovers from when we

Re: Background images

2005-01-30 Thread Glen Mazza
Jeremias Maerki wrote: Team, I'm going to implement background images as one of my next steps. I found that even in 1.1 WD there's no way to scale the background image. Should we skip that or should we define our own properties? Maybe Glen wants to talk to the WG about that. Jeremias Maerki

(housekeeping) need Compare class, TestConverter.getLogger()/.setLogger()?

2005-01-22 Thread Glen Mazza
Hello--three questions: Is anyone using the get/setLogger() methods within TestConverter? (It is coded to use a SimpleLog by default.) I think these two methods are holdovers from when we switched from the Avalon Logger--which needed these methods--to the Commons Logger--which doesn't. Also,

Re: Layout dimension mechanism

2005-01-22 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm beginning to think that the layout dimensions should be held and provided by the layout managers instead of the FObjs. (learning here...) Can you point me towards FObjs which are currently holding the layout dimensions -- I want to try to

Re: Background images

2005-01-20 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Team, I'm going to implement background images as one of my next steps. Good. I found that even in 1.1 WD there's no way to scale the background image. Jeremias, please do another scan first of the 1.1 document--thankfully it's all in one

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/xml XMLRenderer.java

2005-01-19 Thread Glen Mazza
I don't think this is needed (unless I'm missing your reasoning here.) The validation in the FO Tree would raise errors otherwise, at least one page-sequence being required by the fo:root FO. The validation scheme was designed so you don't need subsequent safety checks further downstream.

Re: marketing Defoe

2005-01-17 Thread Glen Mazza
(Don't let Peter rattle you, Jeremias--he's just jealous that I've found more XSL spec bugs than him. ;) Our delays are mostly related to advanced issues concerning layout, and the type of parser used doesn't have much effect on this issue. So I don't share Peter's conviction that FOP is in

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr BlockLayoutManager.java

2005-01-17 Thread Glen Mazza
Yes, I think that's my fault. I believe that was related to the space-before and space-after properties which I was trying (unsuccessfully) to fix. This is a very complex portion of the code. Glen --- [EMAIL PROTECTED] wrote: jeremias2005/01/17 10:59:50 Modified:

bring XSL 1.1 fo:flow-map into HEAD?

2005-01-13 Thread Glen Mazza
Team, The bookmarks are finished. In doing them, I found perhaps about 10 bugs in the 1.1 spec with them (mostly typos but a few functional ones as well), and I sent emails to the XSL-Editors list about those. Next, I'd like to start this weekend looking into bringing fo:flow-map [1] into our

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java

2005-01-11 Thread Glen Mazza
True, but for all times save the first, it ends up being a cached-value get. Repeated across all the FO's, the ratio would appear to be about 90% get/10% original make. I wanted to stress in the code that we are not necessarily making a brand-new property object each time it is applicable for an

Re: Checking for OutputSource for renderer overrides

2005-01-11 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Personally, I would rather we get rid of RendererFactory and put the logic back where it was--in FOTreeBuilder and RenderPagesModel. This functionality is just too specific to be reused elsewhere in FOP. I don't see your point and you

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

2005-01-10 Thread Glen Mazza
BTW, would Jeremias' proposal effect future implementation of the property value functions[1]? Thanks, Glen [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8624-Property-Value-Functions --- Simon Pepping [EMAIL PROTECTED] wrote: Section 5.3.2 of the spec is really hard to

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

2005-01-10 Thread Glen Mazza
--- Glen Mazza [EMAIL PROTECTED] wrote: BTW, would Jeremias' proposal effect future ^^ oopsaffect ;) Glen

Re: Checking for OutputSource for renderer overrides

2005-01-08 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I think you're confusing things. Yes, I think I was. If someone embeds FOP in his/her application the not supplying an OutputStream when a renderer needs one is a bug and so it doesn't matter if the error message comes early or only when the

Re: Checking for OutputSource for renderer overrides

2005-01-07 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: You're right, my change was suboptimal. When I think about this I must say that I'd prefer to remove that check entirely and let the individual renderers check if they have everything to write to their target. I don't think so, because we need

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/properties BoxPropShorthandParser.java

2005-01-06 Thread Glen Mazza
--- Finn Bock [EMAIL PROTECTED] wrote: Using casts will prevent us from adding property proxies, which i suspect will be needed. head-scratch/ What's a property proxy? Can you elaborate on that--give a simple scenario of it? Thanks, Glen

Checking for OutputSource for renderer overrides

2005-01-06 Thread Glen Mazza
Jeremias, Per your change here [1], no longer checking for an OutputStream variable if the Renderer is overridden: The render constant chosen is irrelevant when the renderer is overridden. So the embedded programmer can rely on RENDER_AWT or _PRINT for those comparatively rare cases of not

Re: [RT] FOP RTF edition

2005-01-05 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I'd like to test the waters and see what you guys think about separately releasing the RTF part, or in other words: FOP RTF edition. My $0.02: Looks like busywork--I don't see how this would help you or any other committer. I would be concerned

Re: Implementing text-decoration

2005-01-05 Thread Glen Mazza
I looked at the code and I can't see anything wrong with your suggestion. Unfortunately I'm far from an expert in this area of the code. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should

Re: fo.InlineLevel -- make abstract?

2005-01-05 Thread Glen Mazza
Done. Thanks both for the quick response. Glen --- Simon Pepping [EMAIL PROTECTED] wrote: I agree as well. Regards, Simon On Tue, Jan 04, 2005 at 09:39:14AM +0100, Jeremias Maerki wrote: I think, you are right. They should be abstract. On 04.01.2005 00:47:29 Glen Mazza wrote

Re: New year - update copyright years

2005-01-04 Thread Glen Mazza
{Sigh.} Jeremias, you are so particular--anyway, Peter, will you please give Jeremias said greeting so he can proceed? Thanks, Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I've got a script from Thomas to do that but I need a good day to do that. :-) Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

2005-01-03 Thread Glen Mazza
Jeremias, Would you please elaborate on the need for this? I want to make sure that adding an additional dependency on the Avalon project is passing a cost-benefit analysis here. We're not a fluffy hi-level word processing system --we are a very low-level application (like a compiler), that is

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

2005-01-03 Thread Glen Mazza
+1! Ausgezeichnet! Danke... Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: Sorry, I'm so used to using A-F Enums that I didn't think about that. I've fixed this and hope that you can agree with my change now.

fo.InlineLevel -- make abstract?

2005-01-03 Thread Glen Mazza
Simon, Any problem with making fo.InlineLevel an abstract class? Any reason why you made it instantiable--or was this just an oversight? (Actually, anyone know why we're not making FObj and FObjMixed abstract as well? I might be missing something here...) Thanks, Glen

Re: Happy New Year

2004-12-31 Thread Glen Mazza
2005? Oooh--what's it like?--is everyone going around in space ships? ;) Glen (7 1/2 hours more to go) --- Peter B. West [EMAIL PROTECTED] wrote: Greetings from the future. Happy New Year. Welcome to 2005. Peter

Re: Tweaking the FO class hierarchy

2004-12-28 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm currently playing around with external-graphic and instream-foreign-object as you may have seen. It's my attempt to dive into the whole layout engine thing. Yes, I was very surprised and happy to see you working in layout! I realize that

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread Glen Mazza
Simon, Why aren't these fatal errors--what's the gain in having FOP continue running in an invalid state? One-in-a-million bugs like these that occur for inexplicable reasons should raise an IllegalStateException and halt. FOP should not continue running after catastrophic failures. Glen ---

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread Glen Mazza
This doesn't seem appropriate--the business logic to determine whether or not a layout manager is needed for a particular FO should be within that FO object, where it reads its own private variables--in whatever manner it is internally constucted--and makes its own determination. Otherwise (1)

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread Glen Mazza
--- Simon Pepping [EMAIL PROTECTED] wrote: Glen, In my view the FO system knows nothing about the LM system. It appears that you've just made a friend in Colorado. ;) That is how the LM system can be pluggable. Not really, it can still be pluggable if you have addLayoutManager() in

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2004-12-27 Thread Glen Mazza
--- Simon Pepping [EMAIL PROTECTED] wrote: snip/ I have contained its effect by catching the exception, and have not explored the stack of methods that may need to declare the throwing of an exception. That is a problem in its own right, to be solved at another moment. OK...sorry to be

Re: Horizontal Line

2004-12-27 Thread Glen Mazza
Please use FOP-USER, to help in future searching of the ML archives. Developers are on both lists. Glen --- Puppala, Kumar (LNG-DAY) [EMAIL PROTECTED] wrote: Hello All, Does anyone know what FO tags I need to use to generate a horizontal line given the width, color and justification for

Re: arabic pdf

2004-12-25 Thread Glen Mazza
The squeaky wheel doesn't always get the grease. Send your question to FOP-USER. Glen --- nafise hassani [EMAIL PROTECTED] wrote: Anybody knows how to Create PDF with Arabic words? Seems FOP-0.20.5 cannot handle Arabic glyphs/ligature properly. It can only display the Arabic characters

Re: [OT] Printing the XSL WD

2004-12-24 Thread Glen Mazza
--- Jeremias Maerki [EMAIL PROTECTED] wrote: How do you guys print out the new XSL WD? I don't manage haven't managed to print this document either in IE or in Firefox without having some of the content being cropped. I use Internet Explorer, move the browser text size to small (next to

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LayoutManagerMaker.java LayoutManagerMapping.java AbstractLayoutManager.java ContentLayoutManager.java LayoutManager.java PageSequenceLayoutManager.java

2004-12-24 Thread Glen Mazza
Simon, Will you please comment this method--the purpose of checkLength is not obvious in meaning at least to me. Thanks, Glen --- [EMAIL PROTECTED] wrote: public LayoutManager makeLayoutManager(FONode node, boolean checkLength) { List lms = new ArrayList();

Merry Christmas everyone!

2004-12-23 Thread Glen Mazza
Merry Christmas! Buon Natale! Vrolijk Kerstfeest! Glædelig Jul! Froehliche Weihnachten! Zalig Kerstfeest!/Joyeux Noël! (OK, think I got everybody... ;-) Regards, Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr AbstractLayoutManager.java

2004-12-21 Thread Glen Mazza
--- [EMAIL PROTECTED] wrote: The property lists are not cloned. For future clarity, it may be good to add this limitation of FONode.clone() (and other ones you're aware of) to its javadoc comment. +/** + * Perform a shallow cloning operation, + * set its parent, and

Re: replace extension bookmarks with XSL 1.1 ones?

2004-12-17 Thread Glen Mazza
face color=red/ ;-) --- Chris Bowditch [EMAIL PROTECTED] wrote: Glen Mazza wrote: They're coming very close (I suspect in a few weeks at the latest) to having a Last Call version--would it be acceptable for you at that stage? I don't mind waiting a little longer. Second edition

RE: replace extension bookmarks with XSL 1.1 ones?

2004-12-15 Thread Glen Mazza
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: the XSL 1.1 WD, but since that's all it is ATM, a 'Working Draft', changing their namespace might be a bit premature (?[*]), They're coming very close (I suspect in a few weeks at the latest) to having a Last Call version--would it be

remove Runnable from PageSequenceLayoutManager?

2004-12-14 Thread Glen Mazza
Team, PageSequenceLayoutManager implements Runnable, theoretically to allow for the layout of each page sequence on separate threads. The more complex logical aspects needed for this to happen (e.g., idref resolution, page numbering) though are not implemented, rendering this feature not very

replace extension bookmarks with XSL 1.1 ones?

2004-12-12 Thread Glen Mazza
Team, Silly confirmation question here -- is the 1.1 XSL Spec's fo:bookmark-tree, fo:bookmark, and fo:bookmark-title [1] basically the same thing as our fox:bookmarks, fox:outline, and fox:title, respectively? (i.e., they're for off-document PDF bookmarks?) Its mandated location [2] in the FO

Re: Another problem with Marker.rebind()

2004-12-08 Thread Glen Mazza
- Original Message - From: Peter B. West [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 8:20 PM Subject: Re: Another problem with Marker.rebind() Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. Peter, are you

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgrKnuthElement.java KnuthBox.java KnuthGlue.java KnuthPenalty.java

2004-12-07 Thread Glen Mazza
Sounds good. --- Luca Furini [EMAIL PROTECTED] wrote: Glen Mazza wrote: Luca, I think we should be using getWidth() instead of getW(), correct? Yes, it would be much clearer! I'm going to rename: getW() - getWidth() getY() - getStretch() getZ() - getShrink() getP

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr KnuthElement.java KnuthBox.java KnuthGlue.java KnuthPenalty.java

2004-12-06 Thread Glen Mazza
Luca, I think we should be using getWidth() instead of getW(), correct? Thanks, Glen --- [EMAIL PROTECTED] wrote: +/** + * Return the width of this element. + */ public int getW() { return width; }

Re: Info on Avalon Framework

2004-12-03 Thread Glen Mazza
body temperature=98.5/ It appears we should switch from Avalon configuration to Commons configuration -- and then drop the Avalon library from HEAD. Thoughts? Thanks, Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: Gang, you may have heard about what happened in Avalon-land. Looks

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

2004-12-01 Thread Glen Mazza
Yes, Jeremias has been serving FOP for four years now! [1][2] (I think it's time for us to give him a raise also... ;) Congrats Jeremias! [1] Earliest emails: http://marc.theaimsgroup.com/?a=9723805961r=1w=2 [2] First email (perhaps):

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow Marker.java

2004-11-30 Thread Glen Mazza
Finn (or anyone else), given that FOText nodes (and possibly other non-formatting object nodes in the future) also have properties, any objections if we move FObj.bind() to FONode.bind()? That would simplify the below code a bit. Thanks, Glen [EMAIL PROTECTED] schrieb: spepping2004/11/30

Re: Knuth linebreaking questions

2004-11-30 Thread Glen Mazza
[Finn] 3) What is the reasoning for doing hyphenation only after threshold=1 fails. Naive common sense tells me that if the user specify hyphenation we should do hyphenation before finding line breaks. [Luca] Finding hyphenation points is time-expansive (all words must be hyphenated, not

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

2004-11-26 Thread Glen Mazza
--- Finn Bock [EMAIL PROTECTED] wrote: We've been doing the same with PR_ (properties) and FO_ (FO's) for quite some time. To avoid a name conflict somewhere. Yes, I was wondering why you didn't originally do that for the enumeration constants as well. I like their self-documenting

Re: Preview for a general XSL-FO processing API

2004-11-26 Thread Glen Mazza
Jeremias Maerki wrote: If there's enough interest I can put the source code for the API plus implementations on my website (or to a SF project or somewhere else). I believe this common API could be interesting in the following months when FOP HEAD advances. It can be used to easily switch

Re: For our American readers...

2004-11-25 Thread Glen Mazza
Thanks (but to Him, not to me!), Glen http://holydays.tripod.com/linc.htm --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Happy Thanksgiving! (--that is the 25th, right? :-P) Greetz, Andreas

Re: Do we need an inherit enumeration constant?

2004-11-25 Thread Glen Mazza
[Finn] It [an INHERIT constant] isn't needed as an enum value because the 'inherit' keyword takes precedence over the other enumeration values. See 5.9.11: The Keyword values take precedence over EnumerationToken. where Keyword is 'inherit'. The code to handle 'inherit' is at line 397

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

2004-11-25 Thread Glen Mazza
--- J.Pietschmann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: gmazza 2004/11/24 13:07:31 2.) Appended EN_ to enumeration constants to make them better SR'able throughout app. Yuk. Having a large number of identifiers in the same scope with an identical prefix isn't very

Re: Unnecessary zipping and backups?

2004-11-24 Thread Glen Mazza
--- The Web Maestro [EMAIL PROTECTED] wrote: On Nov 24, 2004, at 11:52 AM, The Web Maestro wrote: On a similar note, I am 'contemplating' committing the xml-fop/build/ folder ('built' by apache-forrest-0.6). My reasoning for this is two-fold: 1. it contains the FOP web site (which

foundation page updated

2004-11-24 Thread Glen Mazza
XML Graphics is now listed on the foundation page, thanks to David Crossley/Forrest Team: http://www.apache.org/foundation Glen

Unnecessary zipping and backups?

2004-11-23 Thread Glen Mazza
Clay, I'm noticing a lot of .zips and .bak backup files in our cvs directories [1] -- this seems unnecessary and a bit messy for a version control system, as everyone who cvs checkouts or cvs updates is now downloading these files. Instead of zip files, usually the solution is just to cvs

  1   2   3   4   5   6   7   >