Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)
On 15.06.2005 21:32:21 Andreas L. Delmelle wrote: -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi Jeremias, Do you, by chance, intend to visit ApacheCon in Stuttgart in July? (I take this 'you' to be plural) Sure, this is addressed to every FOP committer. Me personally, I did intend to visit when I first received word, but unfortunately I wasn't able to get the necessary time off... A shame though, so close. :-( If you come to Switzerland, tell me! Will certainly do so. I do want to travel to Switzerland very much --in my dreams, I even have a house there :-) Ah well, who knows, one day... Looking forward to it. Jeremias Maerki
Re: Foray's font subsystem for Fop
Hi All,
Just to throw in my 2 cents. Batik Handles this through the
@font-face CSS property. This allows you to provide a mapping
from a CSS font-family (with weight etc) to a font file on disk/network
etc:
@font-face { font-family: CSS Batik SVGFont;
src: url(batikFont.svg#Batik); }
Peter B. West wrote:
J.Pietschmann wrote:
Jeremias Maerki wrote:
Ok, but this assumes that you work in concert with AWT's font subsystem.
Well, AWT doesn't provide a way to get the file for a font, but
we can at least get an AWT Font from a TTF file.
And a Type1 file (Java 5). Java just keeps getting better.
This is _very_ interesting. Do you have a reference on this?
Illustrator has a bad habit of embedding CEF (CFF?) fonts in
SVG - these are Type1 font outlines in a TrueType/OpenType wrapper
If the JDK supports Type1 fonts it might support these now as well
(hoping ;).
Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Hi Peter, ..., and Jenni and I are moving to the UK for 12 months at the end of June, ... Well, if you have plans to cross the channel and visit Belgium during those 12 months, be sure to drop me a line. Maybe we can get together for a beer :-) We plan to cross the channel many, many times. Can't wait to have that beer. Cheers, Andreas Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)
Jeremias Maerki wrote: Do you, by chance, intend to visit ApacheCon in Stuttgart in July? It's relatively expensive, isn't it? I don't know what I will be doing at any particular time. It depends on what work is available to me. If you come to Switzerland, tell me! I certainly will. There are a few of you in the area whom I will contact when we pass through. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: Foray's font subsystem for Fop
Victor, I know you intended that. But use and further develop are two different things. What I was getting at with the license grant thing is the possibility to take your font code and put it FOP code repository (or better XML Graphics Commons when it finally pops into existence, still in the queue with infrastructure). Since it was developed outside the FOP project it wasn't really developed under your Apache CLA. Only you can commit any FOray source code to an ASF code repository, and only if you are are sure that noone else contributed any changes to that code during the development under the FOray project. The other possibility is to get a license grant from you and any other contributor to FOray-Font so we can commit the code ourselves (given we decide to do it). Just to be clear, these are the possibilities: 1. FOP uses FOray-Font (JAR file in lib directory), no license grant necessary, no FOray sources in an ASF repository. 2. FOP forks FOray-Font, license grants are necessary due to ASF policy. 3. You donate FOray-Font (back) to the ASF, development within FOray stops, FOray uses a JAR from XML Graphics Commons, development continues within the XML Graphics Commons area, license grants are necessary due to ASF policy. You can guess from my earlier comments that my preference would be (3), but that's not up to me. (1) is the easiest way but leaves us with an important dependency on a project that I marked as a one-man-show (which is an assumption). I don't really like (2). You see that we need to define what we're really talking about. On 14.06.2005 14:44:15 Victor Mote wrote: Jeremias Maerki wrote: No. Licensing is absolutely no problem in this case. FOray is distributed under the same license as FOP. What we can't simply do is take Victor's (source) code and put it in our code repository without Victor doing a grant to the ASF. That's a matter of ASF policy. We can add a JAR, however. Well, the intent of FOray has always been that its code should be accessible at every level to Apache and to anyone else who wants to use it. If I need to make a special grant to make that clear, show me where to sign. Victor Mote Jeremias Maerki
RE: Foray's font subsystem for Fop
Jeremias Maerki wrote: Just to be clear, these are the possibilities: 1. FOP uses FOray-Font (JAR file in lib directory), no license grant necessary, no FOray sources in an ASF repository. This is my preference. 2. FOP forks FOray-Font, license grants are necessary due to ASF policy. I will be happy to provide such a grant. 3. You donate FOray-Font (back) to the ASF, development within FOray stops, FOray uses a JAR from XML Graphics Commons, development continues within the XML Graphics Commons area, license grants are necessary due to ASF policy. This is essentially what I tried to do from within FOP. It failed miserably. I cannot afford to make that mistake again. More to come later by way of answer to your other emails. Victor Mote
Re: Foray's font subsystem for Fop
Jeremias Maerki wrote: Ideally, a font engine that is shared between two projects should be in a more or less neutral place write-accessible by both parties but as we've seen now there are personal dissonances. I think Victor said he didn't want to collaborate anymore: http://marc.theaimsgroup.com/?l=fop-devm=111263144615399w=2 http://marc.theaimsgroup.com/?l=fop-devm=111265443425492w=2 The problem comes up if Glen starts to veto against using Victor's work, of if Victor can't or won't support our wishes anymore. Again, I will stay out of it if another worked with his code. I don't have time for the font work, but certainly recognize it needs improvement. I'm in layout now--if I don't like the front end it doesn't matter (as much!) anymore, I am now past it. But we've had Victor's front-end architecture for the first of my two years here and my mathematical reduction of it for the second. Improvements on layout have been much more rapid in the second year. I do appreciate your work here, Jeremias, and don't wish to add to your stress level on this. I won't interfere with the font work. Regards, Glen
RE: Foray's font subsystem for Fop
Jeremias Maerki wrote: To state my opinion on this matter: I would like to see Vincent integrating FOray-Font into FOP. There has been some work on fonts compared to the FOP maintenance branch but Victor has invested more time in FOray-Font. Victor's font subsystem is now technically more advanced than what we have. The most interesting feature is the fact that you don't have to create that bloody font metrics file anymore. When that is eventually coupled with automatic font registration then it'll be a killer feature. I Based on current constraints, I don't think automatic font registration is possible. In order to embed a font, you have to have access to the underlying file or at least its contents. Until Java gives us this in its own AWT system, you're going to have to get this information somewhere else. Peter West and I have discussed an interesting idea that I want to explore further, which is taking the external registration information and using it to create System (AWT) fonts -- but that still requires an external registration step. consider this one of the more important tasks to improve user-friendliness. Of course, the same functionality could also be done within FOP but why duplicate the effort? I'm sure there are still a few things that would need to be polished inside FOray-Font but if it helps us taking a step forward then I'm all for it. But that's obviously my technical side speaking. There are a lot of improvements that need to be made to FOrayFont, but it is in every respect IMO a step forward on every axis. Ideally, a font engine that is shared between two projects should be in a more or less neutral place write-accessible by both parties but as we've seen now there are personal dissonances. The problem comes up if Glen starts to veto I have no problem with giving qualified FOP developers write access to FOray. I have close to 3000 hours invested in FOray now, and I have no intention of having that undone, so they'll need to provide some assurances that they understand the FOray way. against using Victor's work, of if Victor can't or won't support our wishes anymore. The latter could be a real problem if we switch to FOray-Font as it is a crucial part in the puzzle. But Victor already provided a potential way to improve that situation: aXSL. If we converted our current font engine to implement the aXSL interface, we can easily switch. The downsides are the need to maintain compatibility with aXSL as it advances and aXSL has first to show that it is capable of handling multiple implementations. Also, see my previous email about grants. If you want, you can pull the FOray code into your repository and hack away. I hope this will always be considered a last resort, but I understand (all too well) the desire not to invest in something that will come back and bite you badly. Looking at this from a distance: 1. From a technical perspective, we should work together, if only to avoid being silly by duplicating work. 2. From a psychological perspective, I don't think the two projects will ever get along. That said, I think Victor and I get along together pretty well. He doesn't even mind discussing stuff with me which is a good sign. Too bad I got so little time discussing some really interesting stuff with him, but I have to concentrate on the layout engine ATM. But there are so many broken glasses on both sides that I doubt we find a way of working together. IMO, the reason you and I get along pretty well is that we are both trying to get work done. If we start out disagreeing about something, we usually eventually come to an agreement, because are guided by reason and common goals. Most importantly, when we disagree, we say why, we try to either teach or learn. I am quite capable of getting along with reasonable people, changing my opinions, and learning from mistakes. You say I don't think the two projects will ever get along. I don't think the two projects will ever by reunified, but I see no reason for them not to get along. There is only one FOP developer that is likely to cause a significant problem, and he has already promised to avoid the matter. And if they can't, everyone's investment is protected. If the FOP developers change their minds and decide to work with you, good. If not, please consider posting a message to the FOray mailing list telling me more about what you are trying to accomplish, and I'll be glad to offer some suggestions if I can. FOray's design not only makes it easier to use FOray code in FOP, but it makes it easier to use FOP code in FOray. That sounds like a suggestion for collaboration to me. Give and take. I hope I'm right, Victor. You know I would really like to work together with you again. It's simply that I'm afraid of the old feelings come back (from whatever side) and the two project teams break off with each other again leaving a
RE: Foray's font subsystem for Fop
Jeremias Maerki wrote: To state my opinion on this matter: I would like to see Vincent integrating FOray-Font into FOP. There has been some work on fonts compared to the FOP maintenance branch but Victor has invested more time in FOray-Font. Victor's font subsystem is now technically more advanced than what we have. The most interesting feature is the fact that you don't have to create that bloody font metrics file anymore. When that is eventually coupled with automatic font registration then it'll be a killer feature. I Based on current constraints, I don't think automatic font registration is possible. In order to embed a font, you have to have access to the underlying file or at least its contents. Until Java gives us this in its own AWT system, you're going to have to get this information somewhere else. Peter West and I have discussed an interesting idea that I want to explore further, which is taking the external registration information and using it to create System (AWT) fonts -- but that still requires an external registration step. consider this one of the more important tasks to improve user-friendliness. Of course, the same functionality could also be done within FOP but why duplicate the effort? I'm sure there are still a few things that would need to be polished inside FOray-Font but if it helps us taking a step forward then I'm all for it. But that's obviously my technical side speaking. There are a lot of improvements that need to be made to FOrayFont, but it is in every respect IMO a step forward on every axis. Ideally, a font engine that is shared between two projects should be in a more or less neutral place write-accessible by both parties but as we've seen now there are personal dissonances. The problem comes up if Glen starts to veto I have no problem with giving qualified FOP developers write access to FOray. I have close to 3000 hours invested in FOray now, and I have no intention of having that undone, so they'll need to provide some assurances that they understand the FOray way. against using Victor's work, of if Victor can't or won't support our wishes anymore. The latter could be a real problem if we switch to FOray-Font as it is a crucial part in the puzzle. But Victor already provided a potential way to improve that situation: aXSL. If we converted our current font engine to implement the aXSL interface, we can easily switch. The downsides are the need to maintain compatibility with aXSL as it advances and aXSL has first to show that it is capable of handling multiple implementations. Also, see my previous email about grants. If you want, you can pull the FOray code into your repository and hack away. I hope this will always be considered a last resort, but I understand (all too well) the desire not to invest in something that will come back and bite you badly. Looking at this from a distance: 1. From a technical perspective, we should work together, if only to avoid being silly by duplicating work. 2. From a psychological perspective, I don't think the two projects will ever get along. That said, I think Victor and I get along together pretty well. He doesn't even mind discussing stuff with me which is a good sign. Too bad I got so little time discussing some really interesting stuff with him, but I have to concentrate on the layout engine ATM. But there are so many broken glasses on both sides that I doubt we find a way of working together. IMO, the reason you and I get along pretty well is that we are both trying to get work done. If we start out disagreeing about something, we usually eventually come to an agreement, because are guided by reason and common goals. Most importantly, when we disagree, we say why, we try to either teach or learn. I am quite capable of getting along with reasonable people, changing my opinions, and learning from mistakes. You say I don't think the two projects will ever get along. I don't think the two projects will ever by reunified, but I see no reason for them not to get along. There is only one FOP developer that is likely to cause a significant problem, and he has already promised to avoid the matter. And if they can't, everyone's investment is protected. If the FOP developers change their minds and decide to work with you, good. If not, please consider posting a message to the FOray mailing list telling me more about what you are trying to accomplish, and I'll be glad to offer some suggestions if I can. FOray's design not only makes it easier to use FOray code in FOP, but it makes it easier to use FOP code in FOray. That sounds like a suggestion for collaboration to me. Give and take. I hope I'm right, Victor. You know I would really like to work together with you again. It's simply that I'm afraid of the old feelings come back (from whatever side) and the two project teams break off with each other again leaving a
RE: Foray's font subsystem for Fop
Glen Mazza wrote: I think Victor said he didn't want to collaborate anymore: http://marc.theaimsgroup.com/?l=fop-devm=111263144615399w=2 http://marc.theaimsgroup.com/?l=fop-devm=111265443425492w=2 Even those on this list who are not native English speakers will be able to easily understand the difference between my efforts at collaboration between our two projects have utterly failed at every level and I don't want to collaborate anymore. Again, I will stay out of it if another worked with his code. I don't have time for the font work, but certainly recognize it needs improvement. I'm in layout now--if I don't like the front end it doesn't matter (as much!) anymore, I am now past it. But we've had Victor's front-end architecture for the first of my two years here and my mathematical reduction of it for the second. This actually confirms what I have suspected all along. You never ever EVER saw my front-end architecture. It never made it into FOP. If I had a list of 1000 changes that needed to be made, you took a snapshot after #9 had just been completed and decided that because that did not meet your standards, it should be killed. It didn't meet anyone's standards, certainly not mine. Improvements on layout have been much more rapid in the second year. This is pure speculation with no shred of reasonable nexus. I have a favorite alternate history theory as well that has FOP modularization work done in March, 2004, FOP 0.21 released in April, 2004. At this point ALL modules can be improved without giving up benefits of working code, and developers start doing so. Font refactoring is completed by July, 2004. That and other improvements were released in August, 2004, and Victor was then free to work on the new layout system. Mine is just as much speculation as yours (although I can point to how it worked in FOray). Victor Mote
RE: Foray's font subsystem for Fop
Glen Mazza wrote: I think Victor said he didn't want to collaborate anymore: http://marc.theaimsgroup.com/?l=fop-devm=111263144615399w=2 http://marc.theaimsgroup.com/?l=fop-devm=111265443425492w=2 Even those on this list who are not native English speakers will be able to easily understand the difference between my efforts at collaboration between our two projects have utterly failed at every level and I don't want to collaborate anymore. Again, I will stay out of it if another worked with his code. I don't have time for the font work, but certainly recognize it needs improvement. I'm in layout now--if I don't like the front end it doesn't matter (as much!) anymore, I am now past it. But we've had Victor's front-end architecture for the first of my two years here and my mathematical reduction of it for the second. This actually confirms what I have suspected all along. You never ever EVER saw my front-end architecture. It never made it into FOP. If I had a list of 1000 changes that needed to be made, you took a snapshot after #9 had just been completed and decided that because that did not meet your standards, it should be killed. It didn't meet anyone's standards, certainly not mine. Improvements on layout have been much more rapid in the second year. This is pure speculation with no shred of reasonable nexus. I have a favorite alternate history theory as well that has FOP modularization work done in March, 2004, FOP 0.21 released in April, 2004. At this point ALL modules can be improved without giving up benefits of working code, and developers start doing so. Font refactoring is completed by July, 2004. That and other improvements were released in August, 2004, and Victor was then free to work on the new layout system. Mine is just as much speculation as yours (although I can point to how it worked in FOray). Victor Mote
Re: Foray's font subsystem for Fop
Thanks, Glen, for your statement earlier. And I apologize for jumping to early conclusions about your expected behaviour. I've been burnt a few times so I get jumpy. Victor, your offer for write access on FOray for qualified developers is greatly appreciated and does away with some of my fears about making FOray-Font a FOP dependency. And thanks for taking the time for your explanations. So I think this is a matter of polling the remaining committers on what they think about using FOray-Font (and aXSL for that matter) a dependency of FOP (binary JAR file in the lib dir), so we can profit from a better font support. I'd appreciate any statements even if it's a don't care. We'd have a volunteer who would do it for us, and I'd certainly keep an eye on it and serve as reviewer. But I don't have time to do the actual foot work here. Jeremias Maerki
RE: Foray's font subsystem for Fop
Jeremias Maerki wrote: The logging problem is a minor one. There's a wrapper for JCL that easily wraps an Avalon Logger [1]. But that's obviously the exact opposite of what you need. On the other side, creating an implementation of Avalon's Logger interface that wraps a JCL logger should be just as easy. Unfortunately, such a class doesn't exist, yet, but that's written within 10 minutes. Let me explain why we switched from Avalon Logging to JCL. Avalon Loggers are always passed from container to child object (Inversion of Control). A class using a JCL logger always fetches a logger from a factory. So the difference is in acquiring a logger but there's also another aspect: With Avalon Logger you can use different loggers on different instances of the same class which you can't if you use the normal JCL pattern of using a static variable for holding the logger. The static variable has certain advantages, too: You don't need a variable on every object instance and you don't have to pass Loggers all around in the system, which is particularly problematic or at least cumbersome in FOP. JCL makes many thing easier. But as I hinted above there's no problem connecting the two approaches. Both are light-weight and therefore easy to handle. [1] http://jakarta.apache.org/commons/logging/api/org/apache/commo ns/logging/impl/AvalonLogger.html Thanks for the explanation. I went to a lot of trouble in FOray, mostly based on past conversations with you, to remove all such static-ish things, and I probably won't do anything that would require a client application to use anything like that. But maybe there are some other things that can be done. Foray addresses the logging problem through its tree organization (everything is a tree), and storing the Logger instance at the top of the tree, each child node being able to get the Logger instance from its parent. The only times it needs to get passed as a parameter is when moving from one module to another. So, for example if PDFDocument is at the top of the tree in the FOrayPDF module, it probably requires a Logger in its constructor, but then makes it available to all of its children. In some cases (like FOrayFont) it must be provided through an interface to keep the module as independent as it needs. During our previous Inversion of Control discussion, I briefly toyed with the idea of having the FontConsumer provide a method *to do its own logging*. So, rather than FontConsumer providing a Logger to FontServer (which you did not like), it would instead provide something like: public void logMessage(String message, int messageLevel) ; where messageLevel would indicate whether the message was debug, error, warning, etc. The things I dislike about this are 1) it is YALP (yet another logging protocol), which is what I understood Avalon to be trying to unify, and 2) it requires the client side to write code that seems pretty redundant. However, it is a pretty generic solution. One alternative would be for FontServer and FontConsumer to both allow Commons loggers as well as Avalon loggers, and for it to deal with the wrapping, etc. If it will help and if there are no better ideas, I am willing to do this. Victor Mote
RE: Foray's font subsystem for Fop
Jeremias Maerki wrote: Ok, but this assumes that you work in concert with AWT's font subsystem. If we talk about the font subsystem for PDF and PS we have all liberties we want. If we can give the FO processor a directory and it makes all the fonts in this directory available for FO processing then I am where I would like to be. Of course, there will be some additional topic such as This is very doable (although I would not have thought to call it auto-registration). Foray does not rely on anything in the font configuration to tell it what kind of font file it is working on -- in other words, it parses enough of each file already to create instances of the correct font subclass. It would not be hard to write a method that opens a directory and creates font instances for each file in that directory. Except ... font substitution and embedding control, but if we can make ... and even font naming. One of the things that the configuration file does is provide (at least potentially) an unambiguous and cross-platform way of declaring the relationships between fonts in various families and the mapping between what they are called in an FO document and how they are found in the system. the font registration a no-brainer for at least 60% of the people we've accomplished a lot. The Java2D/AWT renderer is a different story. There we have to work with what we are given. I really wonder if Peter will really stay with the 100% AWT approach till the end. Most people will want to point the auto-registration to C:\WINDOWS\FONTS. Mine has 581 files in it, each of which would have to be opened and partially parsed. I actually use no more than 10-15 for FO work. I think this might actually open up a bunch of potentially ugly support issues, and I would think twice about it. Nevertheless, it can be done. As far as Peter's ideas in this area, I want to spend more time on them. There is a great divide in FOrayFont between what we call FreeStandingFont (those read from disk) and SystemFont (the AWT fonts). Ideally it would be nice for those to be merged. Since an AWT font can be created from a font on disk, if those metrics are suitable for layout, then the disk font can be used for embedding (this can't be done with AWT fonts returned by the java runtime, because it doesn't tell you where the physical file is or what are its contents). That whole idea deserves more thought and experimentation, and I haven't had time to work on the font system since October. Victor Mote
Re: Foray's font subsystem for Fop
On 14.06.2005 17:29:01 Victor Mote wrote: Jeremias Maerki wrote: The logging problem is a minor one. There's a wrapper for JCL that easily wraps an Avalon Logger [1]. But that's obviously the exact opposite of what you need. On the other side, creating an implementation of Avalon's Logger interface that wraps a JCL logger should be just as easy. Unfortunately, such a class doesn't exist, yet, but that's written within 10 minutes. Let me explain why we switched from Avalon Logging to JCL. Avalon Loggers are always passed from container to child object (Inversion of Control). A class using a JCL logger always fetches a logger from a factory. So the difference is in acquiring a logger but there's also another aspect: With Avalon Logger you can use different loggers on different instances of the same class which you can't if you use the normal JCL pattern of using a static variable for holding the logger. The static variable has certain advantages, too: You don't need a variable on every object instance and you don't have to pass Loggers all around in the system, which is particularly problematic or at least cumbersome in FOP. JCL makes many thing easier. But as I hinted above there's no problem connecting the two approaches. Both are light-weight and therefore easy to handle. [1] http://jakarta.apache.org/commons/logging/api/org/apache/commo ns/logging/impl/AvalonLogger.html Thanks for the explanation. I went to a lot of trouble in FOray, mostly based on past conversations with you, to remove all such static-ish things, and I probably won't do anything that would require a client application to use anything like that. But maybe there are some other things that can be done. I've seen that work and I'm sure it was worth it. Relying on static variables in the case of logging is not necessarily bad. I know I advocated the use of Avalon Logger at that time. I still think it is good. The big advantage is really to be able to provide a new logger instance for each processing run so you can log each document separately which you can't if you use JCL's static logging pattern. But I've learned from several people as well as from my own experience that especially in the case of FOP the Avalon Logging approach can be annoying and that per-processing-run loggin should be done through a different mechanism, such as specialized, application-specific interfaces. I haven't been able to get to the latter, yet. It's one of my long term goals to provide better feedback to the caller about layout problems or progress, as well as cleaner exception throwing. Foray addresses the logging problem through its tree organization (everything is a tree), and storing the Logger instance at the top of the tree, each child node being able to get the Logger instance from its parent. The question here, of course, is if it is performant. It's probably ver little but still, in a deep tree a logging call causes a number of method calls to determine the logger instance. The only times it needs to get passed as a parameter is when moving from one module to another. So, for example if PDFDocument is at the top of the tree in the FOrayPDF module, it probably requires a Logger in its constructor, The pure Avalon spirit would be to have that class implement LogEnabled. but then makes it available to all of its children. In some cases (like FOrayFont) it must be provided through an interface to keep the module as independent as it needs. During our previous Inversion of Control discussion, I briefly toyed with the idea of having the FontConsumer provide a method *to do its own logging*. So, rather than FontConsumer providing a Logger to FontServer (which you did not like), it would instead provide something like: The whole discussion there was problematic because I didn't really have time to explain everything to you. But again, I think it was worth it from what I can see. public void logMessage(String message, int messageLevel) ; where messageLevel would indicate whether the message was debug, error, warning, etc. The things I dislike about this are 1) it is YALP (yet another logging protocol), which is what I understood Avalon to be trying to unify, and 2) it requires the client side to write code that seems pretty redundant. However, it is a pretty generic solution. One alternative would be for FontServer and FontConsumer to both allow Commons loggers as well as Avalon loggers, and for it to deal with the wrapping, etc. If it will help and if there are no better ideas, I am willing to do this. I'd leave it as-is for the moment. As I said earlier, I believe it's very easy to wrap a JCL logger into an Avalon Logger and pass that into FontServer and FontConsumer. I'd even say you're on the safer side than FOP because with the static logging you can't separate the logging output for each processing run anymore. This is still
Re: Foray's font subsystem for Fop
On 14.06.2005 17:59:03 Victor Mote wrote: Jeremias Maerki wrote: Ok, but this assumes that you work in concert with AWT's font subsystem. If we talk about the font subsystem for PDF and PS we have all liberties we want. If we can give the FO processor a directory and it makes all the fonts in this directory available for FO processing then I am where I would like to be. Of course, there will be some additional topic such as This is very doable (although I would not have thought to call it auto-registration). Foray does not rely on anything in the font configuration to tell it what kind of font file it is working on -- in other words, it parses enough of each file already to create instances of the correct font subclass. It would not be hard to write a method that opens a directory and creates font instances for each file in that directory. Except ... font substitution and embedding control, but if we can make ... and even font naming. One of the things that the configuration file does is provide (at least potentially) an unambiguous and cross-platform way of declaring the relationships between fonts in various families and the mapping between what they are called in an FO document and how they are found in the system. That's actually what I meant by font substitution. It's good we talked about it. ;-) the font registration a no-brainer for at least 60% of the people we've accomplished a lot. The Java2D/AWT renderer is a different story. There we have to work with what we are given. I really wonder if Peter will really stay with the 100% AWT approach till the end. Most people will want to point the auto-registration to C:\WINDOWS\FONTS. Mine has 581 files in it, each of which would have to be opened and partially parsed. I actually use no more than 10-15 for FO work. I think this might actually open up a bunch of potentially ugly support issues, and I would think twice about it. Nevertheless, it can be done. Not necessarily. I thought about that. We would have to create some sort of font cache file which holds the most important info to avoid parsing every font before it's really used. I've seen that even the old Acrobat Reader 4.05 on Linux did something like that. As far as Peter's ideas in this area, I want to spend more time on them. There is a great divide in FOrayFont between what we call FreeStandingFont (those read from disk) and SystemFont (the AWT fonts). Ideally it would be nice for those to be merged. Since an AWT font can be created from a font on disk, if those metrics are suitable for layout, then the disk font can be used for embedding (this can't be done with AWT fonts returned by the java runtime, because it doesn't tell you where the physical file is or what are its contents). And the reported metrics seem to be different! That whole idea deserves more thought and experimentation, and I haven't had time to work on the font system since October. Absolutely. It would be great if it could be made to work but I seriously doubt it. At any rate I wish Peter the best of luck with his approach. I hope he'll be a happy customer of our Graphics2D implementations when they are separated in the XML Graphics Commons area. :-) Jeremias Maerki
RE: Foray's font subsystem for Fop
Jeremias Maerki wrote: Most people will want to point the auto-registration to C:\WINDOWS\FONTS. Mine has 581 files in it, each of which would have to be opened and partially parsed. I actually use no more than 10-15 for FO work. I think this might actually open up a bunch of potentially ugly support issues, and I would think twice about it. Nevertheless, it can be done. Not necessarily. I thought about that. We would have to create some sort of font cache file which holds the most important info to avoid parsing every font before it's really used. I've seen that even the old Acrobat Reader 4.05 on Linux did something like that. It is an interesting idea. I would probably tend to implement it, at least in the beginning, as a batch job that simply reads a directory of font files and spits out a font-configuration file for the contents of that directory. That saves the user some trouble, but still gives him control (and responsibility) over the output. If your application tries to take responsibility for this, then you will end up needing to reconcile the cache with reality every time anyway, which defeats the purpose of the cache. There is a good reason that fonts tend to evolve into an o/s service. Victor Mote
Re: Foray's font subsystem for Fop
On 14.06.2005 23:27:44 J.Pietschmann wrote: Jeremias Maerki wrote: Relying on static variables in the case of logging is not necessarily bad. *cough* This depends on whether a single logger for all threads is not necessarily bad. I personally would probably prefer the possibility to direct logging for different threads into different destinations. Me too, if you read everything I wrote. And you can strike the probably for me. That statement was pretty general. That's why I talked about an application-specific interface for special logging and notification purposes. You could place the instance in a thread-local. Probably not all logging needs to be per processing run. But some applications will want specific and ideally parseable info back. Jeremias Maerki
Re: Foray's font subsystem for Fop
Victor Mote wrote: Jeremias Maerki wrote: Just to be clear, these are the possibilities: 1. FOP uses FOray-Font (JAR file in lib directory), no license grant necessary, no FOray sources in an ASF repository. This is my preference. 2. FOP forks FOray-Font, license grants are necessary due to ASF policy. I will be happy to provide such a grant. 3. You donate FOray-Font (back) to the ASF, development within FOray stops, FOray uses a JAR from XML Graphics Commons, development continues within the XML Graphics Commons area, license grants are necessary due to ASF policy. This is essentially what I tried to do from within FOP. It failed miserably. I cannot afford to make that mistake again. More to come later by way of answer to your other emails. I have an interest in the future of FOray-Font, so my preference is shared with Victor. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - The atTridged version
Re: Foray's font subsystem for Fop
Jeremias Maerki wrote: On 14.06.2005 17:59:03 Victor Mote wrote: That whole idea deserves more thought and experimentation, and I haven't had time to work on the font system since October. Victor, I have been experiencing similar frustrations, and Jenni and I are moving to the UK for 12 months at the end of June, so I don't expect to have any concentrated development time for a while. Absolutely. It would be great if it could be made to work but I seriously doubt it. At any rate I wish Peter the best of luck with his approach. I hope he'll be a happy customer of our Graphics2D implementations when they are separated in the XML Graphics Commons area. :-) I certainly hope so. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - The atTridged version
Re: Foray's font subsystem for Fop
J.Pietschmann wrote: Jeremias Maerki wrote: Ok, but this assumes that you work in concert with AWT's font subsystem. Well, AWT doesn't provide a way to get the file for a font, but we can at least get an AWT Font from a TTF file. And a Type1 file (Java 5). Java just keeps getting better. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
Re: Foray's font subsystem for Fop
J.Pietschmann wrote: Vincent Hennebert wrote: I was starting to wonder what I could have done wrong so that things turn out that way. Just ignore the bickering for now. There seems to be a law that every Open Source project (or any other reasonably open project for that matter) sooner or later will get people with incompatible personalities, resulting in some mud slinging on mailing lists or worse. Notice the dismissal of one of the core BSD core developers last year, regular flame wars on the Linux Ethernet driver lists including heavy name calling and mutual allegations of incompetence, the fork of Geronimo off JBoss with associated ugliness and so on. No need for you to worry. Let's not forget Linus v. President Tridgell, a dispute with somewhat wider impact. It's almost as bad as proprietary projects, but everything is on public view, everyone gets to express an opinion, and the individuals have real alternatives on how to proceed after disagreements. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version
RE: Foray's font subsystem for Fop
Let's not even start discussing the intellectual property implications that are starting to surface... From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: Tue 6/14/2005 9:22 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Foray's font subsystem for Fop J.Pietschmann wrote: Vincent Hennebert wrote: I was starting to wonder what I could have done wrong so that things turn out that way. Just ignore the bickering for now. There seems to be a law that every Open Source project (or any other reasonably open project for that matter) sooner or later will get people with incompatible personalities, resulting in some mud slinging on mailing lists or worse. Notice the dismissal of one of the core BSD core developers last year, regular flame wars on the Linux Ethernet driver lists including heavy name calling and mutual allegations of incompetence, the fork of Geronimo off JBoss with associated ugliness and so on. No need for you to worry. Let's not forget Linus v. President Tridgell, a dispute with somewhat wider impact. It's almost as bad as proprietary projects, but everything is on public view, everyone gets to express an opinion, and the individuals have real alternatives on how to proceed after disagreements. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ - the atTridged version winmail.dat
Foray's font subsystem for Fop
Hi Fop Team and Victor, I'm considering to adapt Foray's font subsystem to Fop. I have already experimented a bit and the thing seems to be rather feasible. So far I have encountered two problems: - logging mechanism: Foray uses the avalon framework while Fop uses commons logging. The 2 APIs are similar but I suppose I'll have to convert the avalon stuff into commons. Or are there any plans to change the logging mechanism (I'm thinking about the FOPAvalonization Wiki page)? Another minor problem will be to plug the right logger to the font subsystem. I guess only one logger is created and passed through all classes? - the font subsystem is based on a client/server architecture; the question is: which Fop class should be made a FontConsumer? And where should the FontServer be created and held? So far I've used FOEventHandler as a FontConsumer and a holder of a FontServer. It's quite convenient but I'm not sure at all that it is good design; I'm not yet used to Fop's overall architecture. I welcome any additional thoughts/comments. Now starting to work... Regards, Vincent
