fo:inline bpd

Currently fop sets the bpd of areas created from fo:inlines to to line-height of the line the area appears in. For example: Some text smaller text The inline parent area created for the fo:inline will be given a bpd of 12pt, i.e. the line-height of the surrounding block, and not 9.6pt which

Line LM, Inline LM and LAST_AREA

I am trying to understand the logic related to determining if something is the "last area" generated for a LM, in this case for an Inline LM. If I understand it correctly the Line LM sets the LAST_AREA flag in the context when it generates the last area for a line. The Inline LM then checks if

RE: Logging for FOrayFont

J.Pietschmann wrote: > If you've looked into a fair number of open source projects, > and add projects from your work environment, you'll probably > see certain abstractions over and over again. > Counting the number of reincarnations, logging certainly > comes into the top ten, I guess even at

Classpath setup problem

Hi devs, I just upgraded to Ant 1.6.5 and the junit tasks stopped working (see Ant FAQ faq.html#delegating-classloader). I really liked my setup where all jars were in a single directory. :-( It's too late in the evening for advanced reshuffling of important libraries. What's your setup? J.Pietsc

Re: Logging for FOrayFont

Victor Mote wrote: Your meaning here is, at best, ambiguous. Please clarify. If you've looked into a fair number of open source projects, and add projects from your work environment, you'll probably see certain abstractions over and over again. Counting the number of reincarnations, logging cer

RE: Relative font weights and font selection

Victor Mote wrote (August 27, 2005): > > > In order to move forward, I suggest the addition of the following > > > methods in > > > org.axsl.font.Font: > > > > > > public byte nextBolderWeight(); > > > public byte nextLighterWeight(); > > > public org.axsl.font.Font nextBolderFont();

Re: Logging for FOrayFont

I'm sorry but I've got to stop here. No energy left for this discussion. I didn't manage to get my meaning across and so we're talking about different things. I'll try to look into aXSL and FOray later and see if I can create a patch to demonstrate what I was talking about. Sorry for wasting your t

Re: [VOTE] Manuel Mall as new FOP committer

+1 from me also! On Sep 5, 2005, at 1:29 AM, Jeremias Maerki wrote: Manuel Mall has been investing a tremendous amount of time and effort into making FOP better lately. The results were just great. It's been a pleasure to apply his patches, even though it ate up a lot of my time. ;-) Manuel has

Re: Build error

Weird, why does it want Service? I've added SubInputStream and all runs through. On 05.09.2005 22:17:41 Simon Pepping wrote: > On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote: > > You can't, I can. My fault, sorry. > > http://svn.apache.org/viewcvs?rev=278816&view=rev > > Thanks,

RE: Logging for FOrayFont

J.Pietschmann wrote: > > /me ducks. > > Hehe. I've also thought again that designing certain > interfaces (and piling them on each other) must be really really fun. Your meaning here is, at best, ambiguous. Please clarify. Victor Mote

RE: Logging for FOrayFont

Jeremias Maerki wrote: > > A PseudoLogger is required (but can be passed > > null) in the FontServer constructor > > That's an implementation detail and not a problem. It has > nothing to do with the API. FontServer is an interface in the > API and you are talking about the implementation of >

Re: Build error

On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote: > You can't, I can. My fault, sorry. > http://svn.apache.org/viewcvs?rev=278816&view=rev Thanks, that works. Another error, in junit: [junit] Testcase: testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase):

Re: Logging for FOrayFont

As I said, widely differing views between Batik and FOP about this. In my own personal opinion, I'm with you. From the POV of XML Graphics Commons we have a problem. We've voted on the plan for Commons where we said that we'd try to remove the dependency on Commons Logging. If there is a problem wi

Re: Logging for FOrayFont

Jeremias Maerki wrote: I'm ever growing more cofident that developer-oriented logging should be done through a static logging facility (like Commons Logging) and that end-user-oriented logging needs to operate per processing run (like Avalon Logger) but not necessarily through a standard logging

Re: Build error

You can't, I can. My fault, sorry. http://svn.apache.org/viewcvs?rev=278816&view=rev On 05.09.2005 21:02:16 Simon Pepping wrote: > Hi, > > I get a build error: > > [javac] Compiling 653 source files to > /fsb/fsc/source/xml-fop/build/classes > [javac] > /fsb/fsc/source/xml-fop/src/java

Re: [VOTE] Manuel Mall as new FOP committer

+1 from me. Regards, Simon On Mon, Sep 05, 2005 at 10:29:36AM +0200, Jeremias Maerki wrote: > Manuel Mall has been investing a tremendous amount of time and effort > into making FOP better lately. The results were just great. It's been a > pleasure to apply his patches, even though it ate up a lo

Re: Logging for FOrayFont

On Mon, Sep 05, 2005 at 07:33:33PM +0200, Jeremias Maerki wrote: > > On 05.09.2005 17:05:48 Victor Mote wrote: > > Jeremias Maerki wrote: > > > > The design considerations are as follows: > > 1. FOrayFont needs to be able to log messages. > > For whom? For the developer or for the end-user? Beca

Build error

Hi, I get a build error: [javac] Compiling 653 source files to /fsb/fsc/source/xml-fop/build/classes [javac] /fsb/fsc/source/xml-fop/src/java/org/apache/fop/render/ps/PSFontUtils.java:166: cannot resolve symbol [javac] symbol : method copy (org.apache.fop.util.SubInputStream,org.a

Re: [ANN] new aXSL interface for FO Tree

Victor, I find this certainly interesting. IN principle, it would allow client programs, say an editor, to construct its own implementation of the FOTree interface. Simon On Sat, Sep 03, 2005 at 04:45:33PM -0600, Victor Mote wrote: > FWIW, I completed today the extraction of a set of interfaces

Re: Logging for FOrayFont

On 05.09.2005 17:05:48 Victor Mote wrote: > Jeremias Maerki wrote: > > > I got a little shock when I realized a problem I didn't think > > of when we discussed moving FOP components over to XML > > Graphics Commons. We said we would try to remove logging code > > from these basic components en

Re: Logging for FOrayFont

I'm satisfied with your explanations. Please just add a LEVEL_DEBUG constant and I'm OK with your interface. OK, I have added the constant LEVEL_DEBUG back, and have also added a new one called LEVEL_TRACE. PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was equal to LEVEL_F

RE: Logging for FOrayFont

Vincent Hennebert wrote: > Victor Mote a écrit : > > Actually there is not a level named "debug", although I might have > > defined that constant equal to "finest" in one of the > earlier versions. > This does not appear in CVS. I would suggest you to redefine > such a constant to remove any am

DO NOT REPLY [Bug 36508] - Padding-* attributes handling in RTF-rendering

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 36508] New: - Padding-* attributes handling in RTF-rendering

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

Re: [VOTE] Manuel Mall as new FOP committer

On Sep 5, 2005, at 10:29, Jeremias Maerki wrote: Manuel Mall ... That's why I'd like to nominate him for committership in Apache FOP. Definitely a BIG +1 from me. Cheers, Andreas

DO NOT REPLY [Bug 36505] - [PATCH] SVG bugs in Java2D renderers

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 36505] New: - [PATCH] SVG bugs in Java2D renderers

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

RE: Logging for FOrayFont

Jeremias Maerki wrote: > I got a little shock when I realized a problem I didn't think > of when we discussed moving FOP components over to XML > Graphics Commons. We said we would try to remove logging code > from these basic components entirely. > > Now, I forgot to consider the decision to u

Re: e-g with padding and borders

On Mon, 5 Sep 2005 09:51 pm, Jeremias Maerki wrote: > I think you're reaching a point where you should understand exactly > how the Knuth model works. It had to happen eventually :-). > I haven't looked at how conditionality is > implemented very closely. Without diving deeper into this myself

Re: SVG Image cropping/positioning

Richard W. wrote: I'm starting now. I've had to rename inline_block_nested_\#36248.xml to inline_block_nested_bug36248.xml to get the junit task to build. I had to rename that file too; I have win xp. Regards Luca

Re: SVG Image cropping/positioning

Fixed: http://svn.apache.org/viewcvs?rev=278753&view=rev http://svn.apache.org/viewcvs?rev=278754&view=rev On 05.09.2005 15:53:47 richardw wrote: > Jeremias Maerki writes: > > > > I'm starting now. I've had to rename inline_block_nested_\#36248.xml > > > > to inline_block_nested_bug36248.xml to

Re: e-g with padding and borders

Jeremias Maerki wrote: I think you're reaching a point where you should understand exactly how the Knuth model works. I haven't looked at how conditionality is implemented very closely. Without diving deeper into this myself I'm unable to help right now other than to point you to BlockStackingLa

Re: SVG Image cropping/positioning

Jeremias Maerki wrote: ipda is the absolute position in the Inline Progress Dimension (x coord in Left to Right Mode) Nope. ipda is the allocated inline-progression-dimension which is the "ipd" above plus the start and end border and padding widths, i.e. the allocation rectangle. "a" stands

Re: SVG Image cropping/positioning

Jeremias Maerki writes: > > > I'm starting now. I've had to rename inline_block_nested_\#36248.xml > > > to inline_block_nested_bug36248.xml to get the junit task to build. > > Unix Which OS? Linux, Richard

Re: e-g with padding and borders

I think you're reaching a point where you should understand exactly how the Knuth model works. I haven't looked at how conditionality is implemented very closely. Without diving deeper into this myself I'm unable to help right now other than to point you to BlockStackingLayoutManager again which co

Re: SVG Image cropping/positioning

On 05.09.2005 15:30:20 Chris Bowditch wrote: > [EMAIL PROTECTED] wrote: > > > Jeremias Maerki writes: > > > I haven't found anything odd, yet. Looking forward to your test cases. > > > > I'm starting now. I've had to rename inline_block_nested_\#36248.xml > > to inline_block_nested_bug36248.xml

Re: SVG Image cropping/positioning

[EMAIL PROTECTED] wrote: Jeremias Maerki writes: > I haven't found anything odd, yet. Looking forward to your test cases. I'm starting now. I've had to rename inline_block_nested_\#36248.xml to inline_block_nested_bug36248.xml to get the junit task to build. Can you please point me to an expl

Re: SVG Image cropping/positioning

Jeremias Maerki writes: > I haven't found anything odd, yet. Looking forward to your test cases. I'm starting now. I've had to rename inline_block_nested_\#36248.xml to inline_block_nested_bug36248.xml to get the junit task to build. Can you please point me to an explaination of the following:

Re: e-g with padding and borders

On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote: > Jeremias, > > thanks for your patience in answering my questions. > > On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote: > > On 04.09.2005 16:34:35 Manuel Mall wrote: > > > Another question for the "Knuth" experts. It appears the inline > > > LMs

DO NOT REPLY [Bug 36480] - [PATCH] Space support in RTF rendering

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 36479] - [PATCH] Bookmarks don't work in RTF rendering

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 36476] - [PATCH] Border attributes handling in RTF rendering

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

Re: [VOTE] Manuel Mall as new FOP committer

[Jeremias] Manuel Mall has been investing a tremendous amount of time and effort into making FOP better lately. The results were just great. It's been a pleasure to apply his patches, even though it ate up a lot of my time. ;-) Manuel has been around since at least late 2002, even submitted a pa

DO NOT REPLY [Bug 36477] - [PATCH] Start-indent and end-indent attributes in RTF rendering

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 36476] - [PATCH] Border attributes handling in RTF rendering

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 36476] - [PATCH] Border attributes handling in RTF rendering

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

Re: [VOTE] Manuel Mall as new FOP committer

Jeremias Maerki schrieb: > Manuel Mall has been investing a tremendous amount of time and effort > into making FOP better lately. The results were just great. It's been a > pleasure to apply his patches, even though it ate up a lot of my time. > ;-) Manuel has been around since at least late 2002,

DO NOT REPLY [Bug 36475] - Background-color attribute handling for fo:block in RTF rendering

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 36475] - Background-color attribute handling for fo:block in RTF rendering

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

Re: Logging for FOrayFont

Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont

DO NOT REPLY [Bug 36475] - Background-color attribute handling for fo:block in RTF rendering

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

Re: [VOTE] Manuel Mall as new FOP committer

Jeremias Maerki wrote: Manuel Mall has been investing a tremendous amount of time and effort into making FOP better lately. The results were just great. It's been a pleasure to apply his patches, even though it ate up a lot of my time. ;-) Manuel has been around since at least late 2002, even su

[VOTE] Manuel Mall as new FOP committer

Jeremias Maerki wrote: That's why I'd like to nominate him for committership in Apache FOP. +1 Luca