DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size= and font-size=

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size= and font-size=

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size= and font-size=

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size= and font-size=

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Log message when committing patches

Devs, when you apply a patch from someone please use the standard template in the log message: Submitted by: 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' l

Re: DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size= and font-size=

--- 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 t

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: font-weight="bold" produces an area tree output like: font-weight="bold" Is that to be expected, i.e. only some select

Re: font-weight in area tree

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: font-weight="bold" produces an area tree output like: vpos="10266">font-weight="bold" Is that to be ex

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.2

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 proj

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 th

OutOfMemory Problem (multiple PDF-Documents)

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 :   -.pdf     In

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 spec

DO NOT REPLY [Bug 35992] - FOP Compliance page update

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35998] - [PATCH] rtflib independance from FOP

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

XML Graphics Commons: last call

People, I want to finally get through with this. I've put it up for much too long. This is the last call for comments and suggestions on my XML Graphics Commons proposal on the Wiki: http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents I'm sending this also to both subproject dev lists o

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: . .. ...

Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class

Jeremias Maerki wrote: So what's left to be done in your POV? I have to read the current code first. 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