cvs commit: xml-fop/src/documentation/content/design/alt.design PropertyValue.html
pbwest 2002/12/21 20:16:46 Added: src/documentation/content/design/alt.design PropertyValue.html Log: Htmlized code. Revision ChangesPath 1.1 xml-fop/src/documentation/content/design/alt.design/PropertyValue.html Index: PropertyValue.html === PropertyValue.java package org.apache.fop.datatypes; import org.apache.fop.fo.expr.PropertyException; import org.apache.fop.fo.FONode; import org.apache.fop.datastructs.ROStringArray; /* * PropertyValue.java * $Id: PropertyValue.html,v 1.1 2002/12/22 04:16:46 pbwest Exp $ * * Created: Tue Nov 20 22:18:11 2001 * 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. * @author Peter B. West * @version $Revision: 1.1 $ $Name: $ */ /** * Base interface for all property value types. */ public interface PropertyValue { public static final int NO_TYPE = 0 ,ANGLE = 1 ,AUTO = 2 ,BOOL = 3 ,COLOR_TYPE = 4 ,COUNTRY = 5 ,ENUM = 6 ,FONT_FAMILY = 7 ,FREQUENCY = 8 ,FROM_NEAREST_SPECIFIED = 9 ,FROM_PARENT = 10 ,INHERIT = 11 ,INHERITED_VALUE = 12 ,INTEGER = 13 ,LANGUAGE = 14 ,LITERAL = 15 ,MAPPED_NUMERIC = 16 ,MIME_TYPE = 17 ,NCNAME = 18 ,NONE = 19 ,NUMERIC = 20 ,SCRIPT = 21 ,SHADOW_EFFECT = 22 ,SLASH = 23 ,TEXT_DECORATIONS = 24 ,TEXT_DECORATOR = 25 ,TIME = 26 ,URI_TYPE = 27 ,LIST = 28 ,LAST_PROPERTY_TYPE = LIST; public static final ROStringArray propertyTypes = new ROStringArray(new String[] { "NO_TYPE" ,"ANGLE" ,"AUTO" ,"BOOL" ,"COLOR_TYPE" ,"COUNTRY" ,"ENUM" ,"FONT_FAMILY" ,"FREQUENCY" ,"FROM_NEAREST_SPECIFIED" ,"FROM_PARENT" ,"INHERIT" ,"INHERITED_VALUE" ,"INTEGER" ,"LANGUAGE" ,"LITERAL" ,"MAPPED_NUMERIC" ,"MIME_TYPE" ,"NCNAME" ,"NONE" ,"NUMERIC" ,"SCRIPT" ,"SHADOW_EFFECT" ,"SLASH"
cvs commit: xml-fop/src/documentation/content/xdocs tabs.xml
pbwest 2002/12/21 20:14:40 Modified:src/documentation/content/xdocs tabs.xml Log: Fixed headings. Replaced Redesign tab with Development, Redesign and alt design. Revision ChangesPath 1.3 +11 -9 xml-fop/src/documentation/content/xdocs/tabs.xml Index: tabs.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/tabs.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- tabs.xml 19 Nov 2002 07:57:27 - 1.2 +++ tabs.xml 22 Dec 2002 04:14:40 - 1.3 @@ -2,12 +2,14 @@ http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/tab-cocoon-v10.dtd";> - http://www.w3.org/1999/xlink";> - - - - - +http://www.w3.org/1999/xlink";> + + + + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/design/alt.design AbsolutePosition-png.xml BorderCommonStyle-png.xml Properties-png.xml PropertyConsts-png.xml VerticalAlign-png.xml
pbwest 2002/12/21 19:59:35 Removed: src/documentation/content/xdocs/design/alt.design AbsolutePosition-png.xml BorderCommonStyle-png.xml Properties-png.xml PropertyConsts-png.xml VerticalAlign-png.xml Log: No longer required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/design/alt.design layoutmanagers.xml
pbwest 2002/12/21 19:36:11 Added: docs/design/alt.design layoutmanagers.xml Log: Cleaning up. Revision ChangesPath 1.1 xml-fop/docs/design/alt.design/layoutmanagers.xml Index: layoutmanagers.xml === http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd";> Layout managers Layout managers in FOP What do the layout managers do? Most layout is is "automatic" in the sense of being a straightforward stacking operation. Sibling inline-areas, including fo:character areas, are stacked in line-areas in the inline-progression-direction. Sibling block-areas, including line-areas, are stacked in the block-progression-direction. In the simple cases in which both the available block-progression-dimension and the available inline-progression-dimension are known, this process can be driven bottom-up. Available dimensions trickle down from the top, and the bottom level galleys can determine when their available areas are full and suspend pending the arrival of more areas. Such full notifications bubble back up the tree of active galleys. E.g., if an inline galley fills a line-area of a given inline-p-d and suspends while still within the available block-p-d, the parent block-area galley will simply stack the inline-area and notify the inline galley to continue. If the inline-galley discovers that the next line-area that it would generate will not fit in the the block-p-d, it suspends with a notification to that effect to its parent. In more complex cases the dimensions may not be fully specified, or decisions about layout may depend on later layout. In all such cases some layout look-ahead is required which can report results back to higher layout levels. The job for a layout manager in these cirucmstances is to evaluate the information flowing back and set parameters for the best fit layout. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PDF transforms (was: Re: File prefix again)
On Thu, 2002-12-19 at 18:05, Keiron Liddle wrote: > On Wed, 2002-12-18 at 15:23, Nicola Ken Barozzi wrote: > > > I don't get this. How can PDFs be transformed? > > > > There are Java libraries that read PDFs. What would be really cool is to > > have a reader or something like it that uses a PDF as a template. > > Using FOP for just filling out forms is overkill, we just need templating. > > > > This is a general use case of PDF transformation, and another that I > > would really like to see is to generate a "non-controlled copy" stamp on > > the PDF for the management of ISO9001 documentation. > > > > Or simply by adding a copyright statement. > > Sounds like some good ideas. > > It would be possible to do some work with Fop so that it can: > - convert xsl:fo to paged xml Is the paged XML a new or existing format? > - convert paged xml to pdf (or other formats) > - define templates with the paged xml > - append paged xml to a current document > > So it would be possible to create the paged xml from fo. Then to do a > transform or directly convert or append the paged xml to pdf. > Also the extensions and foreign xml can be passed through directly so > that both formats support the same extensions, such as svg. > > So the changes that would need to be made are: > - improve and update xml renderer so that it can output SAX > - improve and update AreaTreeBuilder so that it takes SAX input > - make some additions to the pdf lib so it can load and read pdf > documents > > Then it shouldn't be so hard to add in extensions for pdf forms etc. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://www.rocketred.com.au/blogs/kevin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Happy Holidays
Arved Sandstrom wrote: > I'd like to wish everyone here happy holidays, whatever is appropriate. > > This is a good crowd. Hear, hear! I must agree on both counts. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bidi in the branch
Jeremias Maerki wrote: Hi Peter On 20.12.2002 00:30:13 Peter B. West wrote: Jeremias Maerki wrote: :-) Ok, you're sentenced to implement the same functionality in the trunk. I'm -0 for the inclusion in the branch as it sends the wrong message IMO. But I'm looking forward to seeing bidi support in action in the trunk. Jeremias, I would encourage Oleg to bring this functionality into HEAD. Didn't I? :-) Yes; right above. Call my comment an extended +0 for the sentence you imposed. If it already exists in Oleg's working copy of the maint branch (for reasons which have frequently been canvassed here), I think it would be churlish of us to deny access to our faithful band of users. I would agree was it not for something that is an argument for the redesign. And read again, please. I wrote -0, not -1. I don't deny anything to anybody, just expressing an opinion. Same here - just an opinion. That's why I went for a +0. So, fop-0_20_2-maintain +0. 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]
Re: Happy Holidays
On 21.12.2002 10:51:50 Bertrand Delacretaz wrote: > Happy Holidays team - I've been very quiet lately but this is > *definitely* a good crowd, I wish I could spend more time "here"! Same from me. At least, I'm happy to actually have time to spend here during the next couple of months, maybe more. Happy Holidays! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF transforms (was: Re: File prefix again)
Hi Keiron On 20.12.2002 09:41:52 Keiron Liddle wrote: > On Thu, 2002-12-19 at 21:15, Jeremias Maerki wrote: > > All cool, but how exactly is that better than having a PDF template that > > is stitched behind or in front of the FOP result using iText or PJ? > > Works well. Ok, PDF reading with our own library is a bonus as is better > > XML output for debugging. But I don't see any immediate need for this at > > the moment given our limited resources. Or do I miss anything? > > Well I'm not really suggesting is is high priority, just an idea. > One things is that the XML and the additions can work both in and out of > Fop. > > At least outputing SAX in the XMLRenderer would probably be an > improvement. Ok then. Will you put this on the todo list? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bidi in the branch
Hi Peter On 20.12.2002 00:30:13 Peter B. West wrote: > Jeremias Maerki wrote: > > :-) Ok, you're sentenced to implement the same functionality in the > > trunk. I'm -0 for the inclusion in the branch as it sends the wrong > > message IMO. But I'm looking forward to seeing bidi support in action in > > the trunk. > > Jeremias, > > I would encourage Oleg to bring this functionality into HEAD. Didn't I? :-) > If it > already exists in Oleg's working copy of the maint branch (for reasons > which have frequently been canvassed here), I think it would be churlish > of us to deny access to our faithful band of users. I would agree was it not for something that is an argument for the redesign. And read again, please. I wrote -0, not -1. I don't deny anything to anybody, just expressing an opinion. > So, fop-0_20_2-maintain +0. > > Peter > > > > On 19.12.2002 18:11:02 Oleg Tkachenko wrote: > > > >>Hello there! > >> > >>I know, shame on me, shame on me, but I've implemented partial bidi support in > >>the branch. Sorry, it was urgent commercial requirement. > >>It seems to be working ok (QA is still verifying it though), but of course > >>it's a patch actually and I don't like it much. My question is: should I > >>commit it to the branch codebase? I'm inclining to implement it in a clean way > >>in the trunk instead of extending/patching the branch. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Happy Holidays
Happy Holidays team - I've been very quiet lately but this is *definitely* a good crowd, I wish I could spend more time "here"! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
