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 submitted a patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. +1 from me. Congratulations Manuel! Your work is nothing short of brilliant and your committership is well deserved. Chris
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 made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide. snip/ Chris
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, even submitted a patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. And as he stated his goal is to help to get FOP 1.0 out of the door in a relatively short timeframe (meaning months not years) +1 Christian
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 patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. +1 regards, finn
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36476. 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=36476 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-05 13:35 --- Applied. Thanks! http://svn.apache.org/viewcvs?rev=278720view=rev A comment: It is important to note that the grouping of borders among consecutive blocks with the same border specifications violates the XSL-FO specifications. I found an RTF command in the RTF spec v1.7 (brdrbtw) which seems to address this but I couldn't make it work. -- 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: 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: snip/ Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. Thanks for the pointer. I'll have a look at that. That seem to have done the trick. I have copied the Border/Padding before/after logic from BlockStackingLayoutManager and made it into a Border/Padding start/end for the Inline LM. There were some side effects in that the Line LM expectd only KnuthInlineBoxes and now we have some KnuthBoxes as well but I think I solved that ok. Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? snip/ Jeremias Maerki Manuel Manuel
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 contains at least part of the code that deals with space conditionality. If the comments are right in BlockStackingLayoutManager conditionality has not even been implemented for blocks in the b-p-d. If you really want to go down that road I suggest you get Donald Knuth's Digital Typography or another book that contains the essay Breaking Paragraphs into Lines. There may also be a little information about handling conditionality in the mailing list archives. Sorry that I can't help more, but we're getting into complicated terrain here. On 05.09.2005 14:52:23 Manuel Mall wrote: 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: snip/ Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. Thanks for the pointer. I'll have a look at that. That seem to have done the trick. I have copied the Border/Padding before/after logic from BlockStackingLayoutManager and made it into a Border/Padding start/end for the Inline LM. There were some side effects in that the Line LM expectd only KnuthInlineBoxes and now we have some KnuthBoxes as well but I think I solved that ok. Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? snip/ Jeremias Maerki Manuel Manuel Jeremias Maerki
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
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 BlockStackingLayoutManager again which contains at least part of the code that deals with space conditionality. If the comments are right in BlockStackingLayoutManager conditionality has not even been implemented for blocks in the b-p-d. We discussed this just the other day, and I thought the outcome was that space conditionality for blocks in bpd is implemented, but precedence isn't yet. snip/ Chris
Re: SVG Image cropping/positioning
Fixed: http://svn.apache.org/viewcvs?rev=278753view=rev http://svn.apache.org/viewcvs?rev=278754view=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 get the junit task to build. Unix Which OS? Linux, Richard Jeremias Maerki
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: 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 I'm unable to help right now other than to point you to BlockStackingLayoutManager again which contains at least part of the code that deals with space conditionality. If the comments are right in BlockStackingLayoutManager conditionality has not even been implemented for blocks in the b-p-d. If you really want to go down that road I suggest you get Donald Knuth's Digital Typography or another book that contains the essay Breaking Paragraphs into Lines. There may also be a little information about handling conditionality in the mailing list archives. Sorry that I can't help more, but we're getting into complicated terrain here. That's fine - I am just trying to extract as much information as possible the easy way first. Also, even if conditionality is not implemented may be some of the original designers of the implementation would like to share their thoughts on this topic? I'll see if I can get my hand on the book in the university library here (btw - I am in Perth - Western Australia). In the meantime I'll stick with the discard model which happens to be the default anyway. Manuel On 05.09.2005 14:52:23 Manuel Mall wrote: 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: snip/ Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. Thanks for the pointer. I'll have a look at that. That seem to have done the trick. I have copied the Border/Padding before/after logic from BlockStackingLayoutManager and made it into a Border/Padding start/end for the Inline LM. There were some side effects in that the Line LM expectd only KnuthInlineBoxes and now we have some KnuthBoxes as well but I think I solved that ok. Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? snip/ Jeremias Maerki Manuel Manuel Jeremias Maerki
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36505. 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=36505 Summary: [PATCH] SVG bugs in Java2D renderers Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The following bugs have been found in the Java2D renderer's SVG handling: 1. Whenever two svg images appear on the same page, the second one disappears completely. This was caused by the translate at the end of renderSVGDocument method not being the correct inverse of the preceding one. 2. Any attempt to scale the image failed. Fixed by using the position's width and height rather than the image's. 3. Any attempt to use an image larger than 100x100 caused erroneous cropping. Fixed by scaling as above. However, if the image is larger than 100x100 and no viewbox is defined in the svg file, cropping will still occur. This restriction also holds for PDF (and other?) renderers. -- 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 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36505. 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=36505 --- Additional Comments From [EMAIL PROTECTED] 2005-09-05 17:23 --- Created an attachment (id=16310) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16310action=view) Patch for java2d/svg bugs -- 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: [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 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36508. 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=36508 --- Additional Comments From [EMAIL PROTECTED] 2005-09-05 18:01 --- Created an attachment (id=16311) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16311action=view) [PATCH] Handling of padding attributes are supported Was: padding-related attributes were ignored. Became: When border is specified, all padding attributes are recognized. When border is not specified, padding added to space-* attributes. -- 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: 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_FINEST), and LEVEL_TRACE has been set equal to LEVEL_FINEST. These changes have been made to better accommodate what I understand the Commons Logging levels to be. This makes the Avalon mapping look like this: FINEST debug FINER debug FINEinfo CONFIG info INFOinfo WARNING warn SEVERE error That's fine for me! Thank you, Vincent
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 entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Well, the little change I just made removes entirely any dependency on Avalon in any FOray code, except for the fact that Ant seems to need it for logging (needed for creating hyphenation patterns and such). There is no longer any Avalon code in FOrayFont. In fact, that was the primary motivation for making the change. The Avalon Logger interface would have been quite a sufficient solution for anything that FOray needs, and, since it is an interface, adapters could be written from it to anything else, just as Vincent and I have been discussing for the PseudoLogger interface. Yeah, yet another generic logger abstraction interface. Sigh. Aside from that, a thought about the aXSL APIs: Being an ex-Avaloner SoC (separation of concerns) is a big concern to me. The functional API of a package should IMO actually not deal with (or rather expose) logging at all. It's a separate concern. 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 abstraction interface, but rather an application-specific one that provides exactly what the application needs to send feedback to the end-users. In that light, a PDF or font library shouldn't expose any logging facilities at all or at least to static logging that is externally configured. First, do you understand that the FOrayFont library does not expose any logging facilities to the client, but instead asks the client to expose the logging facilities to it? Yes. Sorry for the not quite accurate wording plus a typo. Let's try again: [a work interface] shouldn't expose any logging specifica (as they are a separate concern, see Avalon's LogEnabled interface or newer dependency injection systems). If developer-oriented logging is absolutely necessary I prefer static logging (like Commons Logging or Log4J) today. 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 FontServer here, I assume. and is required in a method in FontConsumer. But FontConsumer is implemented on the client side, in which the client application tells FOray about itself. This method getPseudoLogger() is what caught my purist's eye in the first place. It breaks IoC. Second, why should FOray limit its clients to only use static logging? If the client has to expose a static logging mechanism to FOray in order to get static logging to work, what can possibly be wrong with exposing a non-static logging mechanism to FOray? Right now, FOray doesn't care whether static or non-static logging is used. Why should it? Exactly. Why should it? If you remove all logging concerns from the work interface you don't do any assumptions about how logging is done. The presence of getPseudoLogger(), though, produces a strong emphasis on non-static logging. Third, lets define the concern. importantMy understanding of Separation of Concerns in this case is that FOrayFont owns the concern that a message needs to be logged, and that the client application owns the concern of how that logging should be accomplished./important In order to maintain that Separation of Concerns, one of two things must happen: 1. The client must tell the component how stuff should be logged. 2. The server must tell the client what should be logged. This means some logging-related stuff will appear in the interface between the two. Not IMO. It can be an implementation detail. See more below. 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? Because that's what I've learned during the past months: That it should be well divided between the two audiences. The speciality is that the developer doesn't need a logger per processing run (i.e. non-static logging) and the end-user often needs more than just pure Strings through a generic logging interface. Note that this is not yet reality
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.apache.fop.util.ASCIIHexOutputStream) [javac] location: class org.apache.commons.io.IOUtils [javac] IOUtils.copy(sin, hexOut); [javac]^ [javac] 1 error BUILD FAILED How can I solve this? Simon -- Simon Pepping home page: http://www.leverkruid.nl
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? Because that's what I've learned during the past months: That it should be well divided between the two audiences. The speciality is that the developer doesn't need a logger per processing run (i.e. non-static logging) and the end-user often needs more than just pure Strings through a generic logging interface. Note that this is not yet reality in FOP but I believe it will be soon. Now, I know this has the potential to spark a heated debate again and it raises question marks about the FOrayFont integration, but ATM I really don't know what to do about it right now. I just realized we have a problem here. I/we made promises on general@xmlgraphics.apache.org to try to remove logging and other external dependencies (like Avalon) for the common components because that's something which is very important to the Batik side. So, then, how are those components supposed to log anything? Or, if they are to log using their own static stuff, how can this be configured by the client? Eventually such basic libraries shouldn't log anything anymore. That's the big dilemma I'm sitting in, the one I need to find a way out of. Anyway, ways to remove the necessity to log are: unit tests and stabilization. The problem is getting rid of something so extremely handy but actually completely unnecessary for something basic like a PDF or font library. But I'd never want to get rid of the ability to log in a complex system like a layout engine. I am not sure that I understand everything that is being said here. But I am alarmed when I hear that basic libraries, in this case the FontServer, shouldn't log anymore. In my experience a font system requires powerful logging, in order to expose runtime behaviour to the systems manager or end user. Configuring font systems and understanding why a piece of font software does not use it as you expect, is a hard task that requires suitable runtime information from the software. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
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 lot of my time. ;-) Manuel has been around since at least late 2002, even submitted a patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: Build error
You can't, I can. My fault, sorry. http://svn.apache.org/viewcvs?rev=278816view=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/org/apache/fop/render/ps/PSFontUtils.java:166: cannot resolve symbol [javac] symbol : method copy (org.apache.fop.util.SubInputStream,org.apache.fop.util.ASCIIHexOutputStream) [javac] location: class org.apache.commons.io.IOUtils [javac] IOUtils.copy(sin, hexOut); [javac]^ [javac] 1 error BUILD FAILED How can I solve this? Jeremias Maerki
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 abstraction interface, but rather an application-specific one that provides exactly what the application needs to send feedback to the end-users. That's a major part of the points at the end of http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200508.mbox/[EMAIL PROTECTED] The idea is that FOP sends certain events (or messages) to the User Agent interface and let the app specific user agent implementation sort out whether it wants to log it, throw an exception, show a message box, whatever. The static debug/trace mechanism is a welcomed refinement, I'd thought of exposing the logger from the user agent to the rest of the code for this purpose. It is quite possible that the event signalling methods proposed in the post above need to be split up further. /me ducks. Hehe. I've also thought again that designing certain interfaces (and piling them on each other) must be really really fun. J.Pietschmann
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 with that, the right place to raise this is [EMAIL PROTECTED] On 05.09.2005 21:15:50 Simon Pepping wrote: snip/ I am not sure that I understand everything that is being said here. But I am alarmed when I hear that basic libraries, in this case the FontServer, shouldn't log anymore. In my experience a font system requires powerful logging, in order to expose runtime behaviour to the systems manager or end user. Configuring font systems and understanding why a piece of font software does not use it as you expect, is a hard task that requires suitable runtime information from the software. Jeremias Maerki
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=278816view=rev Thanks, that works. Another error, in junit: [junit] Testcase: testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase): Caused an ERROR [junit] org/apache/fop/util/SubInputStream [junit] java.lang.NoClassDefFoundError: org/apache/fop/util/SubInputStream Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not contain Service and SubInputStream in the util package. Simon -- Simon Pepping home page: http://www.leverkruid.nl
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: 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=278816view=rev Thanks, that works. Another error, in junit: [junit] Testcase: testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase): Caused an ERROR [junit] org/apache/fop/util/SubInputStream [junit] java.lang.NoClassDefFoundError: org/apache/fop/util/SubInputStream Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not contain Service and SubInputStream in the util package. Simon -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
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 time. This was really not directed at you but rather at the FOP team so they know we have a potential problem when moving code over to Commons. It wasn't supposed to extend into such a discussion. I'm anxious to see what happens when I actually start to migrate code to Commons On 05.09.2005 22:29:46 Victor Mote wrote: 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 FontServer here, I assume. Well, it may have nothing to do with the aXSL API, but it certainly has something to do with the FOray API. To implement FOray (which I understand to be the discussion), you have to do both. If it is wrong to demand a logging mechanism in aXSL's API, how can it then be right to do so in FOray's API? It sounds like I could solve all of your concerns by creating a FOray FontConsumer implementation that is an abstract class, making you pick some class to extend it, and then simply demanding a logging mechanism in the implementation's constructor. Am I right? If so, doesn't it all seem silly? The client application now has to have implementation-specific code embedded at FontConsumer (document) construction. Poof. Pluggability just disappeared. For what benefit? None. Your client application still supplies exactly the same thing it supplied the other way. Really, why does FOP care whether it needs to supply logging information because aXSL requires it or because FOray requires it? and is required in a method in FontConsumer. But FontConsumer is implemented on the client side, in which the client application tells FOray about itself. This method getPseudoLogger() is what caught my purist's eye in the first place. It breaks IoC. I don't care. (I am sure that comes across more rudely than I intend). There are more important things here. Second, why should FOray limit its clients to only use static logging? If the client has to expose a static logging mechanism to FOray in order to get static logging to work, what can possibly be wrong with exposing a non-static logging mechanism to FOray? Right now, FOray doesn't care whether static or non-static logging is used. Why should it? Exactly. Why should it? If you remove all logging concerns from the work interface you don't do any assumptions about how logging is done. The presence of getPseudoLogger(), though, produces a strong emphasis on non-static logging. Not true. Your PseudoLogger implementation can use whatever logging it wants to, or, as may please you better, send it to /dev/null. Again, if you accept implementation constructors as part of the API that FOP must deal with, then I think your whole line of reasoning disappears here. Third, lets define the concern. importantMy understanding of Separation of Concerns in this case is that FOrayFont owns the concern that a message needs to be logged, and that the client application owns the concern of how that logging should be accomplished./important In order to maintain that Separation of Concerns, one of two things must happen: 1. The client must tell the component how stuff should be logged. 2. The server must tell the client what should be logged. This means some logging-related stuff will appear in the interface between the two. Not IMO. It can be an implementation detail. See more below. 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? Because Ah, now this is what I consider to be an implementation detail! that's what I've learned during the past months: That it should be well divided between the two audiences. The speciality is that the developer doesn't need a logger per processing run (i.e. non-static logging) and the end-user often needs more than just pure Strings through a generic logging interface. Note that this is not yet reality in FOP but I believe it will be soon. Well, I noticed that you chose to ignore the important tag, and it shows up here. Why should the component concern itself with the differences between the two audiences? If a user wants to log debug or trace messages into a permanent file somewhere, what business is that of FOrayFont's All it should do is respond to the level of detail that is requested by the client application, and to place it where the
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(); public org.axsl.font.Font nextLighterFont(); ... There is another area complexity in font selection that has not yet been addressed, so I pose it here to Vincent and Manuel especially, and to any others who wish to comment. The whole issue of whether the Font has a glyph for the character(s) has not yet been addressed. The best idea I have for this is as follows: 1. Add a char to the signature of org.axsl.font.FontServer.selectFont. This char represents the first char of the text for which the font is being selected. This allows the selection process to pass by a font-family if it cannot paint the character. ... 2. Add the following method to org.axsl.font.Font: /** * Examines each character in string to ensure that a glyph exists in the font for that * character. If a character has no glyph in the font, the character's index in string * is returned. * @return The index in string of its first character for which no glyph exists in this * font. If all characters in the string have glyphs in this font, -1 is returned. */ public int unavailableChar(String string); Add also an overridden version of this method with char[] as the parameter. Why not directly return an array of all indexes where there is a missing glyph? OK. Probably in a separate method called unavailableChars. Or add a beginIndex parameter so that one doesn't have to artificially recreate a String made of the initial String minus all characters up to the first missing glyph? Yes. That definitely needs to be there. The following methods have now been added to org.axsl.font.Font: public byte nextBolderWeight() ; public byte nextLighterWeight() ; public Font nextBolderFont() ; public Font nextLighterFont() ; public int unavailableChar(String string, int beginIndex) ; public int unavailableChar(char[] chars, int beginIndex) ; public int[] unavailableChars(String string, int beginIndex) ; public int[] unavailableChars(char[] chars, int beginIndex) ; and a char has been added to the signature of the method org.axsl.font.FontServer.selectFont. Stub implementations have been created in FOray, but the added functionality is, in general, not actually in place yet. I'll get to that as I am able, but at least those working with the interface can move forward when they are ready. Victor Mote
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 certainly comes into the top ten, I guess even at position three after configuration services and i18n. The tendency to have a project specific abstraction, however small, isn't new, check out the history part in the syslogd docs. If you are interested in a list of other recurring themes beside the three named above: - service discovery, often including loading code or data from a directory or some other repository - URL resolving - URI, URL, pathname and search path handling as Strings - command line argument parsing, maybe as part or complement of a configuration service - object pooling, in particular network connection pooling and multiplexing - XML creation - Java object persistence The list isn't complete of course. J.Pietschmann
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.Pietschmann
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: fo:block font-size=10ptSome text fo:inline font-size=8ptsmaller text/fo:inline/fo:block 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 is the height of the fo:inline. The difference is visually noticeable to moment one applies backgrounds or borders/padding to the fo:inline. Am I correct in saying that the current implementation is incorrect and that the smaller bpd should be applied in the example above? Manuel
