Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java
On 10.01.2005 22:00:01 Simon Pepping wrote: Section 5.3.2 of the spec is really hard to understand. I combine it with 5.1.4 about Inheritance. Then my guess is this: fo:block margin-left=1pcA test file fo:inline-container start-indent=1.5pc fo:block margin-left=1pcA test file/fo:block /fo:inline-container /fo:block The computed value of start-indent on the outer block is 'start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width' = 0 + 1pc + 0 + 0. The computed value of start-indent on the inner block is 'start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width' = 1.5pc + 1pc + 0 + 0. In this case: fo:block margin-left=1pcA test file fo:inline-container fo:block margin-left=1pcA test file/fo:block /fo:inline-container /fo:block the computed value of start-indent on the outer block is 'start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width' = 0 + 1pc + 0 + 0. The computed value of start-indent on the inner block is 'start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width' = 1pc + 1pc + 0 + 0. The inherited value uses the calculated value (sect. 5.1.4). That is the value that should be returned by pList.getParentPropertyList().get(Constants.PR_START_INDENT).getLength(). I agree with your interpretation. The inherited value should not be stored, but used in the computation of the property value. This should be implemented by the property maker. In the meantime I've rewritten that part and removed the two fields I introduced on CommonMarginBlock. But the code needs some more work until I'm ready to check in. All testcases pass again but I don't have any tests for writing mode changes which is important for the MarginPropertyMaker I wrote to get the computed margin values. When I run the above examples in a debugger, I find that the computed start-indent values CommonMarginBlock.startIndent are exactly like I argue above they should be. Yes. There does not seem to be a need to add the inherited value later; the property maker already has done so. See IndentPropertyMaker.compute(PropertyList). It uses propertyList.getInherited(baseMaker.propId).getNumeric()) to get the inherited value. Earlier FOP developers understood this part well. I understand, but I think you're talking exclusively about the property resolution phase (right?) while I found that I need the computed value of the margin property (not only the explicit one as is currently the case) and the inherited start-indent for the layout manager code and to set traits correctly. If you find wrong results, then the problem must be elsewhere. Yes, in the layout managers. Is there a book or treatise on these subjects, where we can read how a knowledgeable author interprets these difficult parts of the spec? I don't know. We're probably stuck with the FO-related mailing lists. Please have patience with me while I'm learning my way into layout. I can already feel my understanding of the whole thing growing from hour to hour and I'm grateful for any insight you can provide. I'm sorry for being a moving target. It's too bad that the ICLayoutManager is still empty so your examples above cannot be tested, yet, but I have other examples that help show similar effects with what already works. Jeremias Maerki
Re: Checking for OutputSource for renderer overrides
On 08.01.2005 19:27:38 Glen Mazza wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: snip/ 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 renderer is started (Renderer.startRenderer()). OK, I see what you're saying here--it would be one time only programmatic change for the user to fix his embedded code. Yes. If I understand you correctly, all that would be needed for renderer overrides is to just raise an exception within Renderer.startRenderer(OutputStream) if the OutputStream is null (for those renderers requiring an OutputStream). Arguably, the Renderer should be programmed to do that anyway, even if it is checked earlier. Yes. That makes sense--and I now agree with your previous change of not checking for an OutputStream when the RendererOverride is set. Thanks for the clarification. (I still prefer the one-line check in RendererFactory for our *hardcoded* renderers--for documentation/comprehension reasons, and it gives us a common error message for our own renderers.) That's ok. I'll do the necessary changes this week. snip/ So here's another one. Do you know about SVG Print? An SVG renderer could send the generated SVG using SAX. That way a developer could run the generated SVG through an XSLT post-processing without having to reparse the generated SVG. That's a place where speed is very important and an OutputStream-only system would be suboptimal. I don't completely understand this idea (Namely, how can you send generated SVG using SAX--wouldn't that mean the generated SVG would have to be in XML format?)--but it doesn't matter anyway because, again, I don't have a problem with your validation change. sending generated SVG using SAX means that all the XML elements that are generated by the SVG Renderer would be sent as start/endElement calls through a ContentHandler interface. I'm doing the same for the ExampleObj2XML class in the embedding examples, only that it's plain custom XML there. You can catch these SAX events with a JAXP Transformer(Handler) and do anything with them: simple serialization to streamed XML (StreamResult), build a DOM (DOMResult), transform using XSLT, whatever. Jeremias Maerki
Re: how to do a table header
Before I begin, a couple of points: - Please don't hijack existing threads. Instead, start a new one and use a descriptive subject. What you do is confusing. - Please send questions to the fop-user mailing list. See http://xml.apache.org/fop/maillist.html A table-header is done like this: fo:table table-layout=fixed fo:table-column. fo:table-column. fo:table-header fo:table-row. /fo:table-header fo:table-body fo:table-row. /fo:table-body /fo:table You might want to get a good XSL-FO reference. On 11.01.2005 04:43:45 Goel, Nitesh wrote: In the region body I am making a table. I want the table header(that row) to be repeated on subsequent pages. How to do that? Jeremias Maerki
DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32970. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32970 --- Additional Comments From [EMAIL PROTECTED] 2005-01-11 10:31 --- I'm extremely reluctant to install a software in a language I don't understand. It's already enough of a pain to have a mixed german/english system. I'm sorry, but I won't install that version of Acrobat. IMO if different Acrobat variant (even with the same version numbers) produce different results it's more of a problem of Acrobat. I'd check if Adobe support has any idea. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32970. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32970 --- Additional Comments From [EMAIL PROTECTED] 2005-01-11 11:00 --- I understand. Meantime, is any way how to embed complete ttf font into PDF document instead needed parts only? http://xml.apache.org/fop/fonts.html writes: ... When embedding TrueType fonts (ttf) or TrueType Collections (ttc), a subset of the original font, containing only the glyphs used, is embedded in the output document. ... XEP includes complette font informations and theirs PDF does not prouce the problem. We have some developers capacity to try to solve such problem ourself, so if some change of souce will help, we can try it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32970. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32970 --- Additional Comments From [EMAIL PROTECTED] 2005-01-11 16:58 --- The description is a bit misleading. FOP embeds the whole font file into the PDF, which is actually a bad idea (CJK fonts files are big). There are additional structures in the PDF which are needed for mapping PDF character indexes into glyph indexes. FOP fills these with data only for characters which have been used in the document. I vaguely remember there are a few more PDF structures still missing. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java
On Tue, Jan 11, 2005 at 09:25:50AM +0100, Jeremias Maerki wrote: On 10.01.2005 22:00:01 Simon Pepping wrote: There does not seem to be a need to add the inherited value later; the property maker already has done so. See IndentPropertyMaker.compute(PropertyList). It uses propertyList.getInherited(baseMaker.propId).getNumeric()) to get the inherited value. Earlier FOP developers understood this part well. I understand, but I think you're talking exclusively about the property resolution phase (right?) while I found that I need the computed value of the margin property (not only the explicit one as is currently the case) and the inherited start-indent for the layout manager code and to set traits correctly. PropertyList().get(Constants.PR_START_INDENT) gets the computed value, that is, the value after property refinement. It is not the raw value stated in the FO file; FOP does not store that at all. FOP tries to do property refinement immediately. If that is not possible because the computed value depends on a trait of an area, FOP stores an expression, which can be computed at layout time. I see no mention in section 5 of the spec that the trait value for start-indent is different from the computed property value. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java
On Tue, Jan 11, 2005 at 12:07:53AM -, [EMAIL PROTECTED] wrote:
gmazza 2005/01/10 16:07:53
Modified:src/java/org/apache/fop/fo Constants.java
FOPropertyMapping.java PropertySets.java
src/java/org/apache/fop/fo/flow MultiCase.java
src/java/org/apache/fop/fo/pagination/bookmarks
Bookmark.java BookmarkTitle.java BookmarkTree.java
Log:
2.) Switch from makeEnumProperty to slightly more intuitive
getEnumProperty in FOPropertyMapping.
It does really make a property value, which is held as in the member
enums in the property maker:
private Property makeEnumProperty(int enumValue, String text) {
if (enums == null) {
enums = new Property[ENUM_COUNT+1];
}
if (enums[enumValue] == null) {
== enums[enumValue] = new EnumProperty(enumValue, text); ===
}
return enums[enumValue];
}
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java
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 FO.
Ultimately, whether a property needs to be maked
(made) or is cached is just an internal implementation
issue with that get() method. (e.g., we could choose
to create all the properties up-front, and then
implement the get() as 100% retrieval instead of
90/10.)
Glen
--- Simon Pepping [EMAIL PROTECTED] wrote:
On Tue, Jan 11, 2005 at 12:07:53AM -,
[EMAIL PROTECTED] wrote:
gmazza 2005/01/10 16:07:53
Modified:src/java/org/apache/fop/fo
Constants.java
FOPropertyMapping.java
PropertySets.java
src/java/org/apache/fop/fo/flow
MultiCase.java
src/java/org/apache/fop/fo/pagination/bookmarks
Bookmark.java
BookmarkTitle.java BookmarkTree.java
Log:
2.) Switch from makeEnumProperty to slightly
more intuitive getEnumProperty in
FOPropertyMapping.
It does really make a property value, which is held
as in the member
enums in the property maker:
private Property makeEnumProperty(int enumValue,
String text) {
if (enums == null) {
enums = new Property[ENUM_COUNT+1];
}
if (enums[enumValue] == null) {
== enums[enumValue] = new
EnumProperty(enumValue, text); ===
}
return enums[enumValue];
}
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Checking for OutputSource for renderer overrides
--- 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 were the only one who complained about the RendererFactory. I still think the RendererFactory is A Good Thing (tm). It reduces imports, dependencies and number of lines in FOTreeBuilder and RenderPagesModel I don't see how adding a class in the renderer package, which fo.FOTreeBuilder and area.RenderPagesModel now must access in order to do their work, reduces the number of dependencies and imports. (Indeed, we now have a new dependency: RendererFactory.) Also, the fact that the new solution has more classes and more overall LOC would appear to invalidate the benefit of there being fewer LOC in FOTB and RPM as a result. Usually for a factory pattern, its biggest selling point is in reuse--i.e., centralizing certain logic so it doesn't have to be duplicated in multiple places. But there is no reuse being realized here. (Perhaps you see some in the future however.) and centralizes instantiation of the Renderers and FOEventHandler in one place where they are easier to find for those unfamiliar with FOP sources. True--but is that an acceptable OO design? Can we indeed just rip out disparate business logic from various classes and place them into one class for convenience? Is there really an object that would know which FOEventHandler an FOTreeBuilder requires *and* which Renderer the RenderPagesModel needs? (They are different issues, after all.) RendererFactory seems to be a C-language-like non-OO collection of business logic, an artificial object, and the fact that it has no class or instance variables would appear to add to that argument. Still, this is just one additional class so hardly an architecture-breaker. (And I can see the convenience regardless of having them together in one place.) So just take this posting as a desire on my part to further clarify my concerns about this class. Thanks, Glen
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java
[Simon] There does not seem to be a need to add the inherited value later; the property maker already has done so. See IndentPropertyMaker.compute(PropertyList). It uses propertyList.getInherited(baseMaker.propId).getNumeric()) to get the inherited value. Earlier FOP developers understood this part well. [Jeremias] I understand, but I think you're talking exclusively about the property resolution phase (right?) while I found that I need the computed value of the margin property (not only the explicit one as is currently the case) and the inherited start-indent for the layout manager code and to set traits correctly. [Simon] PropertyList().get(Constants.PR_START_INDENT) gets the computed value, that is, the value after property refinement. It is not the raw value stated in the FO file; FOP does not store that at all. FOP tries to do property refinement immediately. If that is not possible because the computed value depends on a trait of an area, FOP stores an expression, which can be computed at layout time. I see no mention in section 5 of the spec that the trait value for start-indent is different from the computed property value. The problem that Jeremias is trying to address is computing space-[start,end] traits. Since only start-indent was computed correctly he tried to compute space-[start,end] traits based on the [start,end]-indent and to do that the inherited indent values (which has just been added in IndentPropertyMaker) must be substracted. Which may indicate that calculating space-[start,end] traits based on indents is probably not the right approach. I think the solution would be to: - Store the [start,end]-indent traits. - Let LayoutContent.refIPD be the reference IPD rather than the content ipd of the parent. - let the renderer keep track of the reference rect and use the start-indent trait to locate the position of the content rectangle. regards, finn
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java
Funny! I just came to the same conclusion a few minutes ago. Simon's last comment brought me to that. Simon: I see no mention in section 5 of the spec that the trait value for start-indent is different from the computed property value. I then checked the BlockLayoutManager and realized that what Finn is now saying is exactly what's suboptimal about the current approach. I'm just now reworking the code to implement what Finn suggests. It also lets me forget about that silly and complicated MarginPropertyMaker I started to write. Thanks Guys helping me on the right track! On 12.01.2005 08:42:24 Finn Bock wrote: [Simon] There does not seem to be a need to add the inherited value later; the property maker already has done so. See IndentPropertyMaker.compute(PropertyList). It uses propertyList.getInherited(baseMaker.propId).getNumeric()) to get the inherited value. Earlier FOP developers understood this part well. [Jeremias] I understand, but I think you're talking exclusively about the property resolution phase (right?) while I found that I need the computed value of the margin property (not only the explicit one as is currently the case) and the inherited start-indent for the layout manager code and to set traits correctly. [Simon] PropertyList().get(Constants.PR_START_INDENT) gets the computed value, that is, the value after property refinement. It is not the raw value stated in the FO file; FOP does not store that at all. FOP tries to do property refinement immediately. If that is not possible because the computed value depends on a trait of an area, FOP stores an expression, which can be computed at layout time. I see no mention in section 5 of the spec that the trait value for start-indent is different from the computed property value. The problem that Jeremias is trying to address is computing space-[start,end] traits. Since only start-indent was computed correctly he tried to compute space-[start,end] traits based on the [start,end]-indent and to do that the inherited indent values (which has just been added in IndentPropertyMaker) must be substracted. Which may indicate that calculating space-[start,end] traits based on indents is probably not the right approach. I think the solution would be to: - Store the [start,end]-indent traits. - Let LayoutContent.refIPD be the reference IPD rather than the content ipd of the parent. - let the renderer keep track of the reference rect and use the start-indent trait to locate the position of the content rectangle. Jeremias Maerki
