regions and writing-mode
This is (again) more of a clarifying question as I am looking in that area of the code and I think its incorrect: Am I correct in saying: The position of the before/after/start/end regions on the output media is relative to the writing-mode and reference orientation on the simple-page-master they belong to? Currently some of their positioning is determined by the writing-mode set on the regions themselves, which usually would be the same as on the simple-page-master, but it can be different and then the current implementation seems to get itself confused. Manuel
DO NOT REPLY [Bug 36487] - [PATCH] e-g/i-f-o border/padding, background-image position, regions - margins - writing-mode
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=36487. 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=36487 --- Additional Comments From [EMAIL PROTECTED] 2005-09-03 16:17 --- Created an attachment (id=16297) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16297action=view) The patch -- 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
Hi Victor, What I liked with the Avalon Logger is the one-to-one correspondance between it and Commons' Log; commons just has one more level which is trace. So writing a Logger adapter that delegates logs to a Log instance is trivial. Now it's different because PseudoLogger has 7 log levels + 1 debug level, whereas commons Log has 6 levels with different purposes. The best mapping that I see is the following: PseudoLogger - Log finest trace finer trace finetrace debug debug config info infoinfo warning warn severe error Log's fatal level wouldn't be used. Writing an adapter in the other way would have been somewhat easier (and BTW corresponds to commons' Jdk14Logger). Personally I tend to find Commons log levels more intuitive and useful than the Jdk ones: I don't really know what to do with 3 fine, finer, finest and one config levels. May I suggest you to use Commons' style of levels instead? That said, this is by no means dramatic. For me it's just a matter of writing another wrapper. I agree that it's a bit cleaner if the font system has its own logging rules, independently of other existing logging systems. So no problem for me. Vincent Victor Mote a écrit : I just completed a project to make FOray's logging a bit more flexible. It now logs from an interface called org.axsl.common.PseudoLogger. Logging levels are the same as those for java.util.logging.Level (in Java 1.4 and higher), except that integrals are used instead of Level instances. I also wrote an implementation org.axsl.common.AvalonLogger, which FOray uses (for now) when it needs to *create* a logger. Since all loggers in the font system are supplied to the font system (instead of created within it), FOP should simply pass a different implementation to keep its logging consistent within itself. The AvalonLogger is a thin wrapper around an, er, Avalon ConsoleLogger, and is essentially an Adapter between the Avalon logging system and PseudoLogger. A similar approach can be used with whatever logging system FOP decides it wants to use. Writing the adapter should be fairly trivial, and it should be possible to use any logging system with this approach. I hope this makes the integration work a bit easier and the results more satisfactory to FOP. Please let me know if you have questions. Victor Mote
RE: Logging for FOrayFont
Vincent Hennebert wrote: What I liked with the Avalon Logger is the one-to-one correspondance between it and Commons' Log; commons just has one more level which is trace. So writing a Logger adapter that delegates logs to a Log instance is trivial. Now it's different because PseudoLogger has 7 log levels + 1 debug level, whereas commons Log has 6 levels with different purposes. The best mapping that I see is the following: PseudoLogger - Log finest trace finer trace finetrace debug debug config info infoinfo warning warn severe error Actually there is not a level named debug, although I might have defined that constant equal to finest in one of the earlier versions. Here is the way I mapped the Avalon levels in the AvalonLogger implementation: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/org/axs l/common/AvalonLogger.java?view=markup FINEST debug FINER info FINEinfo CONFIG info INFOinfo WARNING warn SEVERE error Log's fatal level wouldn't be used. Writing an adapter in the other way would have been somewhat easier (and BTW corresponds to commons' Jdk14Logger). Personally I tend to find Commons log levels more intuitive and useful than the Jdk ones: I don't really know what to do with 3 fine, finer, finest and one config levels. May I suggest you to use Commons' style of levels instead? That said, this is by no means dramatic. For me it's just a matter of writing another wrapper. I don't really feel strongly about it either, but perhaps a bit more strongly than you for the following reasons: 1. From a sheer standard aspect, I wanted to stay as close to the Java logging system as possible. I would have used the java.util.logging.Level instances (for type safety) instead of numeric constants, except for trying to retain Java 1.3 compatibility. 2. I prefer to allow for more granularity rather than less (within reason), even if we don't think we need it right now. 3. This is one of those things that you can change on Tuesday to make one party happy, then change back again on Wednesday to make another party happy, all for very little benefit. In short, there is no way to make everyone happy. Also, I don't know if you noticed the following methods: info(String message) warn(String message) error(String message) debug(String message) which correspond directly to the Avalon methods of the same name, and are intended to provide a sort of mapping for them. I don't mind adding one more called trace(String message) if that would make the mapping concept more clear for you. In short, it isn't a big deal to me either, but I would prefer to leave it alone unless there is some compelling reason to change. When you say somewhat easier, we're talking about a pretty trivial difference, right? Probably just 7 case statements instead of 5? If not, I will be glad to rethink this. I agree that it's a bit cleaner if the font system has its own logging rules, independently of other existing logging systems. So no problem for me. Yes, I thought this was pretty nice. The other thing it allowed me to do is to make the FOray logging system very generic. I use the PseudoLogger interface everywhere. When I need to instantiate a logger, I can use a static method to do that. This means that I could switch over to a new logging system for the price of changing the static method and writing a new wrapper/adapter that implements PseudoLogger. Victor Mote
[ANN] new aXSL interface for FO Tree
FWIW, I completed today the extraction of a set of interfaces for aXSL to generically describe an FO Tree. The FOray FOTree implements these interfaces, and the other FOray modules have been changed to use the aXSL interfaces instead of the FOray FOTree implementation. The only dependency within FOray on FOray FOTree now is one that handles creating a default implementation if none is passed to FOraySession. For some time now, the FOray FOTree has been available as an independent module. This new set of interfaces theoretically allow non-FOray FOTree implementations to be used within FOray. I realize that there is not a great demand for this ATM. However, there are numerous immediate benefits: 1. It is now possible to more clearly show rather than merely tell the where and when issues that I described in another thread earlier this week. 2. There is something about having to extract an interface that forces one to address ugly design issues and get them cleaned up. I found and fixed a few. There are probably still some others that will become apparent in a closer review of the interfaces. 3. It opens the door to the possibility of comparing different FO Tree implementations to each other with other components remaining fixed. I don't know whether the FOP FO Tree can be adapted to implement this interface or not, but I suspect that it can. For any who are interested, the code can be conveniently viewed here: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-fotree/src/java/org/axs l/fotree/ The slightly bad news for Jeremias is that the outer-level FOray API has changed to accommodate the new FOTreeServer that allows this pluggability. However, this is easily fixed by passing one more null parameter in the FOraySession constructor. The interfaces are not well documented ATM and are no doubt weak in many other ways as well. A great many of the interfaces are empty markers, providing type identification only. There may be a better way to handle this. Or it may turn out that additional methods will need to be added to them to accommodate more sophisticated needs. I hope this is of general interest to this list, and apologize if it is not. Victor Mote
