DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size=absolute and font-size=relative
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=36036. 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=36036 --- Additional Comments From [EMAIL PROTECTED] 2005-08-05 12:52 --- Actually looking at Commonfont.getFontState() the relative font weights are not (!) implemented (something else to do). One reason Finn couldn't use the same scheme I used for font-sizes is that font-weight does not allow percentage values. Another reason is, as I pointed out, that my implementation is not strictly spec compliant. Both, relative font-weights and relative font-sizes must be implement with reference to the parent value. Now if I could figure out how this property inheritance / resolution stuff is implemented in Fop, i.e. how / where / when I can get to the value of the property in the parent element, I could fix both of these relative properties (and may be some of the other percentage stuff not working). -- 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 36036] - [PATCH] Support for font-size=absolute and font-size=relative
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=36036. 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=36036 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-05 13:32 --- Yes you are right that getFontState() method isn't doing a great deal and as you say this is because the percentage should apply to the parent. I have applied your patch but decided to leave the bodge for relative sizes out for now. There's already a task item to properly implement percentages within FOP's property/FO sub systems. So I think this is best addressed after that work is completed. Thanks for your contribution -- 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.
Log message when committing patches
Devs, when you apply a patch from someone please use the standard template in the log message: Submitted by: name email This is important in case we need to do research into our codebase about who submitted what. It faciliates filtering out these commits. I've already fixed the log messages for Chris' last two commits: http://svn.apache.org/viewcvs?rev=230445view=rev http://svn.apache.org/viewcvs?rev=227398view=rev Thanks! On 05.08.2005 13:30:19 cbowditch wrote: Author: cbowditch Date: Fri Aug 5 04:30:05 2005 New Revision: 230445 URL: http://svn.apache.org/viewcvs?rev=230445view=rev Log: Patch supplied by Manuel Mall in bugzilla 36036 with minor modifications Modified: snip/ Jeremias Maerki
Re: DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size=absolute and font-size=relative
--- Additional Comments From [EMAIL PROTECTED] 2005-08-05 12:13 --- Thanks for doing this. Your patch looks good and appears to work. However, theres one little thing thats puzzling me. Finn, who is our properties guru wrote the class CommonFont. If you look at the method getFontState there is some code that implements the relative keywords for font weight and comments that say should do font size relative keywords too. Why would he write this if all he needed to do was added some keywords to the Property Maker ??? The getFontState() method was copied from somewhere else. I do not remember from where. I believe that the properties should return the documented values without a need for postprocessing (as seen in getFontState()), but I never got around to do it for the font stuff. I guess that the maker for font-size would look a bit like the maker for line-height. regards, finn
font-weight in area tree
I am trying to write a testcase for the font-weight property and noticed that the font-weight property is not shown in the area tree, i.e. something like: fo:block font-weight=boldfont-weight=bold/fo:block produces an area tree output like: block bap=0 0 0 0 bpd=14400 bpda=14400 ipd=595275 ipda=595275 lineArea bap=0 0 0 0 bpd=14400 bpda=14400 ipd=0 text color=#00 font-family=F3 font-size=12000 vpos=10266font-weight=bold/text /lineArea /block Is that to be expected, i.e. only some selected resolved properties are shown in the area tree? Manuel
Re: font-weight in area tree
The font-weight is encoded in the font-family attribute. F3 will internally point to a certain font-triplet which holds the information about font-family, font-weight and font-style. For unit testing, it might be worthwhile to expand F3 into multiple attributes in the XMLRenderer. On 05.08.2005 14:34:16 Manuel Mall wrote: I am trying to write a testcase for the font-weight property and noticed that the font-weight property is not shown in the area tree, i.e. something like: fo:block font-weight=boldfont-weight=bold/fo:block produces an area tree output like: block bap=0 0 0 0 bpd=14400 bpda=14400 ipd=595275 ipda=595275 lineArea bap=0 0 0 0 bpd=14400 bpda=14400 ipd=0 text color=#00 font-family=F3 font-size=12000 vpos=10266font-weight=bold/text /lineArea /block Is that to be expected, i.e. only some selected resolved properties are shown in the area tree? Manuel Jeremias Maerki
RE: svn: eol-style
Jeremias Maerki wrote: Well, for XML Files this is not a big problem usually, but for Java files it usually is. But for text files in general, native EOLs make life easier for certain people. Furthermore, I don't see any such conventions documented (which doesn't mean there's no project standard): http://xml.apache.org/fop/dev/conventions.html Within the ASF in general I see a wide-spread use of the native setting. SVN handles this whole area better than CVS. According to the official doc (several versions available at: http://svnbook.red-bean.com/) Note that Subversion actually stores the files in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though. IOW, regardless of what operating system you run on, the line endings in the repository will always get converted to LF, automatically. The svn:eol-style affects only the checked-out version on the client. And, because the properties are stored in the repository, it affects the line-endings for all clients. The default value of native is almost always the safest way to go. However, I do set my shell-scripts to LF because I usually use a Windows client to get them, but actually run them on a Linux box. Probably would be a good idea to set DOS batch files/scripts to CRLF for the same reason. But most other things are probably best left native. HTH. Victor Mote
Re: svn: eol-style
Victor Mote wrote: Jeremias Maerki wrote: Well, for XML Files this is not a big problem usually, but for Java files it usually is. But for text files in general, native EOLs make life easier for certain people. Furthermore, I don't see any such conventions documented (which doesn't mean there's no project standard): http://xml.apache.org/fop/dev/conventions.html Within the ASF in general I see a wide-spread use of the native setting. SVN handles this whole area better than CVS. According to the official doc (several versions available at: http://svnbook.red-bean.com/) Note that Subversion actually stores the files in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though. Hi Victor, thanks for this. I had basically come to the same conclusion, but wasn't 100% sure. I am glad you have confirmed my suspicions. Chris snip/
Re: OutOfMemory Problem (multiple PDF-Documents)
On 05.08.2005 10:41:39 Andreas Cordes wrote: Hi, I am new to the FOP-Development and I haven't read all the documents yet. I made some modifications to the FOP so I am able to have mutiple PDF Files with one XML File. The Filename is dynamically generated based on a specific FONode. Example : ac:filename xsl:value-of select=name-xsl:value-of select=prename.pdf /ac:filename In a few words, when a new page Sequence starts, I stop and start the PDF Renderer with a new Outputstream. (may be not the best solution) Indeed. I can imagine that this will be a bit hacky. I think it would be cleaner to start a new PDF file within the existing PDF Renderer. It is working very well with a little XML-File. But now I get into trouble. My XML File is about 103193785 Bytes (103 MB !). In this XML-File, there about 16588 Elements which are processed so I will get 16588 files. Everbody with me? :-) It was working very well up to 700 Elements but after that, I got an OutOfMemory. I would have been surprised if it had worked. I know there are currently a few memory leaks hidden in the code. I've done some test on big files myself and quickly found problems with memory consumption. So far nobody had time to do these optimizations, and BTW, it is also too soon to really do them (except if somebody has spare time). I modified the SVN-Version from 3rd of August 2005 and I already tried to increase the Heap to 1024M. (I have 64GB Memory on that server :-)) When I finished this modification to the according way to the fop development guide, I'll do a patch. I have to mention, that I already modified the 0.20.5 Version and tested it successfully with a different, static (concerning the filename) dirty hack. So I got 16588 PDF Documents. With one XML and one XSL file. Jeremias Maerki
handling inline-container (was:Re: Handling of block-level FOs inside fo:inline and related)
Jeremias Maerki wrote: I've no idea if an inline-container is supposed to be broken at all and if yes, how. If the ipd in the inline container is changed to be orthogonal to the ipd of the containing area, the inline-container may be broken across lines: fo:block . fo:inline-container write-mode=tb height=2cm.. ... /fo:inline-container . /fo:block may result in a layout like (container border simulation added for clarity) +-- |.. |.. |.. +-- --+ ..| . | .. . | --+ The container may generate multiple areas similar to a fo:inline with font-size=4cm. Note that the height property on the inline container is mandated by the spec in this case (and maps to the ipd value of the container area). Setting the reference orientation to 90 or 270 instead of the writing mode should result in a similar layout. Trouble starts if the writing-mode resp. reference-orientation doesn't change the inline progression direction. There is still some relief if the inline container only contains a fixed width table, which thereby determines the width of the container itself nicely. From the questions on the FOP lists I gather this will be the most often utilized use case for inline containers, at least until people really start mixing classical chinese with western scripts in a single line. Something like fo:block width=11em qoz fo:inline-container fo:blockfoo bar baz/fo:block /fo:inline-container quz /fo:block is going to be tricky, I'd say it is legal to render is as qoz foo bar baz quz (no line breaks in the block within the container, container broken across lines) as well as foo qoz bar quz baz (block in container broken into 3 lines, container not broken). Unless I missed some restrictions mentioned in the spec, of course. We could probably get away with the following strategy: 1. start with ipd for the container = available space on line 2. if the container overflows in ipd (because a descendant generated an area which is wider than the tentative ipd), undo the layout, create a linebreak before the container, and continue with ipd of the container = line ipd) 3. adjust the container ipd to the maximum ipd of the areas created by the container's children. The example above would be laid out roughly as qoz foo bar baz quz (use you imagination to center the container vertically). The case where the container content causes the line height to grow until the available space in bpd is exhausted could be added, but creates more layout choices, if this happens in step 1, there is a choice between restarting at step 2 or creating a page break before the line (possibly leaving a lot of ugly empty block space at the end of the previous page). And so on :-/ I'd like to see real use cases for this before I maltreat my brain by further thinking about layout strategies. J.Pietschmann
Re: XML Graphics Commons: last call
Jeremias Maerki wrote: The discussion will be exclusively on [EMAIL PROTECTED] I've just detected I'm not subscribed to [EMAIL PROTECTED] Duh! J.Pietschmann
