RE: FAQ'ish questions (was: Re: XHTML 2 PDF)
J.Pietschmann wrote: - What's the current publishing process? Wasn't there a Wiki page about this? It is on the web site, under the Development tab, Deploy/Doc Mgmt menu: http://xml.apache.org/fop/dev/doc.html It may have started as a Wiki -- I don't remember. I don't know whether it is up-to-date or not. Victor Mote
RE: layoutengine test text-transform2.xml
Simon Pepping wrote: Why is this expectation in text-transform2 correct: fo:block2: fo:wrapper text-transform=capitalizeThis tExT is cafo:wrapper color=redpit/fo:wrapperAfo:inline color=blueliZ/fo:inlineed./fo:wrapper/fo:block eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/ Reading the XSL spec, section 7.16.6, I expect 'This Text Is Capitalized' despite the wrapper and inline elements. The spec only speaks about words. There is no mention that fo child elements would make a difference. You are correct. The result should be: This TExT Is CapitAliZed. Victor Mote
RE: layoutengine test text-transform2.xml
Simon Pepping wrote: Why is this expectation in text-transform2 correct: fo:block2: fo:wrapper text-transform=capitalizeThis tExT is cafo:wrapper color=redpit/fo:wrapperAfo:inline color=blueliZ/fo:inlineed./fo:wrapper/fo:block eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/ Reading the XSL spec, section 7.16.6, I expect 'This Text Is Capitalized' despite the wrapper and inline elements. The spec only speaks about words. There is no mention that fo child elements would make a difference. You are correct. The result should be: This TExT Is CapitAliZed. Victor Mote
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
a mess behind. I too am all for collaboration. I doubt that anyone feels the pain of lack of collaboration more than I. Nearly every day I duplicate something that I wish didn't have to be duplicated. But I have to weigh that against probably 1500 hours of work that was flushed at FOP for no good reason (at least none that has ever been explained to me). It is true that duplication of work is a form of waste. So which is better: 1) pay too much for something and still have that something, or 2) pay too much for something and have nothing? I am happy for FOray to collaborate with FOP as two independent entities. I am also happy to collaborate by inviting qualified FOP developers into FOray. But if by collaboration you mean that I will again place myself in a position where Glen or anyone else can simply destroy my efforts, I will not do that. In short FOray is quite willing to get along with FOP, as long as that does not mean being swallowed up by it. So, IMO, if FOray and FOP are unable to get along, I suggest looking within FOP. There is always the possibility that I have wronged FOP or some FOP developers that would cause bad feelings. If so, I hope someone will be man enough (or woman enough) to point such a thing out to me. AFAIK, unless I have already apologized for it, any comments I have made were both just and necessary. The two reasons that make me hesitant to really put energy into reestablishing a mode of collaboration is the high risk of failure, especially given the immediate bad energies that bubbled up following Vincent's proposal, and the fact that I *All* of those bad feelings came from FOP. Vincent and I were having a reasonable technical discussion which was interrupted by mere rants. What you have just established is a principle that says that one person's personal animosity will be allowed to dictate to FOP what its policy shall be. That is clearly not reasonable. Victor Mote
RE: Foray's font subsystem for Fop
a mess behind. I too am all for collaboration. I doubt that anyone feels the pain of lack of collaboration more than I. Nearly every day I duplicate something that I wish didn't have to be duplicated. But I have to weigh that against probably 1500 hours of work that was flushed at FOP for no good reason (at least none that has ever been explained to me). It is true that duplication of work is a form of waste. So which is better: 1) pay too much for something and still have that something, or 2) pay too much for something and have nothing? I am happy for FOray to collaborate with FOP as two independent entities. I am also happy to collaborate by inviting qualified FOP developers into FOray. But if by collaboration you mean that I will again place myself in a position where Glen or anyone else can simply destroy my efforts, I will not do that. In short FOray is quite willing to get along with FOP, as long as that does not mean being swallowed up by it. So, IMO, if FOray and FOP are unable to get along, I suggest looking within FOP. There is always the possibility that I have wronged FOP or some FOP developers that would cause bad feelings. If so, I hope someone will be man enough (or woman enough) to point such a thing out to me. AFAIK, unless I have already apologized for it, any comments I have made were both just and necessary. The two reasons that make me hesitant to really put energy into reestablishing a mode of collaboration is the high risk of failure, especially given the immediate bad energies that bubbled up following Vincent's proposal, and the fact that I *All* of those bad feelings came from FOP. Vincent and I were having a reasonable technical discussion which was interrupted by mere rants. What you have just established is a principle that says that one person's personal animosity will be allowed to dictate to FOP what its policy shall be. That is clearly not reasonable. 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
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
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
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: FOP Compliance Page was: getPageCount and FOP 1.0dev
Manuel Mall wrote: BTW, why do we have the 3 columns Basic | Extended | Complete? Every row will only have one cell out of those 3 filled out. Wouldn't it make more sense to have a single column called Compliance or Core with the values Basic, Extended or Complete? That would save valuable screen space and give us room to add columns for each release. The original compliance page had each cell color-coded to indicate compliance with each of the three levels. So, if feature A is required for Extended support and was not supported by FOP, the Basic column would have the compliant color, while the Extended and Complete columns would have the non-compliant color. I built this just slightly before we converted to Forrest. Since we converted to Forrest, the custom XSLT required for the above has been a pain, and I think it has been eliminated. I just looked at the published page, and it looks like you still have the three columns, but not the color-coding, so combining the three as you suggest makes good sense. (Sorry for the slow response. My email is being bounced as spam). Victor Mote
RE: svn: eol-style
Jeremias Maerki wrote: Well, for XML Files this is not a big problem usually, but for Java files it usually is. But for text files in general, native EOLs make life easier for certain people. Furthermore, I don't see any such conventions documented (which doesn't mean there's no project standard): http://xml.apache.org/fop/dev/conventions.html Within the ASF in general I see a wide-spread use of the native setting. SVN handles this whole area better than CVS. According to the official doc (several versions available at: http://svnbook.red-bean.com/) Note that Subversion actually stores the files in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though. IOW, regardless of what operating system you run on, the line endings in the repository will always get converted to LF, automatically. The svn:eol-style affects only the checked-out version on the client. And, because the properties are stored in the repository, it affects the line-endings for all clients. The default value of native is almost always the safest way to go. However, I do set my shell-scripts to LF because I usually use a Windows client to get them, but actually run them on a Linux box. Probably would be a good idea to set DOS batch files/scripts to CRLF for the same reason. But most other things are probably best left native. HTH. Victor Mote
RE: Relative font weights and font selection
Victor Mote wrote (August 8): Manuel Mall wrote: Regarding the bolder, lighter issue and the general font selection I looked at the pre-patch for FOrayFont adaptation to Fop (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and concluded that meddling with the font selection system will interfere with the FOray font integration and that the FOray font system has addressed most of the font selection issues any way (not sure about the bolder, lighter bits though). I will therefore back-off from that line of work and wait for the FOray font integration to complete, assuming that it is still going ahead. Sorry to be so slow responding. I think Vincent is taking August off, but is still working on the font integration work. Manuel and I have had an off-line conversation about the bolder/lighter issue, and I think we will need to improve both the interface and the implementation to handle this and the similar issues for font-stretch. I'll work on that in the next week or two. First, sorry to be so slow. I can finally get to all my tools again. I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. 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(); This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. 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. Between these two, I think an application should be able to efficiently subdivide a chunk of text based on the various fonts that may need to be used to process it. Comments on any of this are very welcome. I had hoped to defer some of these font selection issues for a while yet, and you guys are frankly ahead of me in needing to resolve them, so I will be glad to react to those who may have thought it through more than I have. BTW, while very briefly looking at parts of the FOray/aXSL font selection code I noticed at least one instance where it relied on a JDK 1.4 API call. Not quite what we want for FOP I believe but I am sure easy to fix for Victor. Yes, we should be able to get a 1.3 solution for this. BTW, FOray is theoretically dependent on 1.4. However, I don't know that there are any 1.4 dependencies in the font code. I have removed the 1.3 dependency noted in aXSL. There may be others that need to be addressed to retrofit for 1.3 use. Victor Mote
RE: Relative font weights and font selection
Jeremias Maerki wrote: I believe that font-stretch has to included just like font-weight to select the actual font. Sorry to be unclear. I understand that font-stretch must be included. The issue is whether the wider and narrower constraints can be processed in the FOTree by simply bumping the description up / down, or whether (as seems to be the case for font-weight) they must be resolved in the font system by looking at the actual fonts available. I originally read the spec to mean the latter, but I think Manuel reads the spec as the former. I am not sure which is right. If the latter is correct, then we will need to do something similar to what I have described for font-weight to handle the font-stretch relative values. For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. I think this is really up to the user agent to define the exact strategy as long as the visual order is preserved. OK. That is a third theory. This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. I got the impression that's what the spec tried to establish. Hmm. I have never seen such a thing explicitly. I have been working under the assumption that font A could be part of two font-families if a user wished to do so. (I am not sure why a user would want to do so -- this was just known to be possible with the data structured as it is). Thanks for your comments. Victor Mote
RE: Relative font weights and font selection
Vincent Hennebert wrote: Victor Mote a écrit : I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! As I understand the spec, this works differently from font-weight and can be resolved in the FO Tree: just select the next expanded value for wider or next condensed for narrower. The font selection would be performed only after, when it is time to decide e.g. which font the keyword semi-expanded matches. That's true that it is an extra-feature that IMO can be simulated with a good font configuration file. Just to be clear, I understand your last sentence to be addressing a different topic than the first part of this statement. That is, font configuration won't be at all involved with the *resolution* of font-stretch in what you have proposed. However, it may be involved from the standpoint of implementing a resolved font-stretch value in that font-stretch could be simulated using PostScript or PDF text parameters. Did I understand this correctly? For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. I'd go with 1. Get the inherited font; find a darker one in the fonts database; get its weight value. That's it. 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(); This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. That seems OK. The only interest I see for a font to belong to several families is when there is a specific family (Times, Helvetica) and a generic one (serif, sans-serif...). In this case a generic family would be mapped to a specific one, and I don't think your proposed methods prevents that. Otherwise I don't see much interest to mix several families to build a complete set. The result would be visually bad IMO. I may have missed something: I haven't studied that point yet. I think you understand it perfectly. You are correct on all points: 1) putting a font in multiple font families is not very important, 2) we can still alias a font-family to another one. 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. So let's assume that I have a line of text to render. IIUC I would use it like this: * first call with the first char of the text to get the font that will be generally used * an additional call for each character for which there is no glyph in the general font Is that what you mean? I guess so. It doesn't sound elegant or efficient, but I haven't thought of a better algorithm. Presumably the common case is that the first font selected works for all of the text. 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. Between
RE: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Manuel Mall wrote: PS: I can imagine Victor smiling now :-) : I told you so that not leaving all property resolution to the LM stage is going to cause trouble. Trust me, I'm not smiling. As one of our U.S. Presidents was known for saying, I feel your pain. In fact, it might be fairly said that FOray exists because I have a lower toleration for such pain than the other FOP developers. Victor Mote
RE: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
Chris Bowditch wrote: This is an excellent goal. Sometimes it is all too easy to aim for 100% perfection and then FOP gets stuck - just like it has been for 2 years prior to 2005. Compromise is the key to getting 1.0 out of the door. This is grossly foul. I don't remember anyone striving for 100% perfection when FOP was stuck. FOP got stuck in large part because 1) it first forked itself (no pun intended), and 2) the perceived leader of the project, who was to make that strategy work, suddenly dropped completely off of the edge of the world. The *ability* to compromise and to allow for multiple solutions to the same problem was one of the driving forces behind the modularization effort. Arggh. I have no problem with you guys sailing your ship however you see fit. But I reserve the right to set the record straight when my own efforts are misrepresented. 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
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: 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
Simon Pepping wrote: It would of course be easier if all components would use a standard interface like Commons Logging. But that is not going to happen in this world. FWIW, I am not opposed to having FOray use Commons Logging instead of a home-grown interface. But that is actually an external dependency as well, so that was not an option. And from the standpoint of a component developer, you have to ask yourself how often you can afford to switch from Avalon to Commons to ... It would (maybe) help some if java itself would endorse an interface for this purpose. Victor Mote
RE: font system: millipoints or floats?
Jeremias Maerki wrote: I don't see a big problem if you switch to points and double for the font library. These values can always be converted back to millipoints as needed. It's a relatively isolated area. After all, we already convert from and to millipoints back and forth. Doing the same for the font library is not a big deal I think. Unless I'm missing something, of course. The only issue I can think of would be the cumulative effect of the performance hit, and I'm not smart enough to predict whether that is significant or not (there are some operations that would be saved internally that might help pay for the expense of a client application converting). I think I will do some experimentation before I go any further with that. Some other day. Thanks for the feedback. Victor Mote
RE: Relative font weights and font selection
Victor Mote wrote (on Monday): 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. FOrayFont now has fully functional implementations of all of these methods, and its font selection logic has been upgraded to use them. With the *possible* exception of font-selection-strategy (I will start a separate thread on this issue shortly), I think that FOray's font selection is now fully conformant. FOrayFOTree has also been upgraded to use the font-selection properly, and to compute the relative font weights using the new aXSL font methods. If it helps, Vincent and Manuel can use this as a template when implementing in FOP. The only real trick in FOray was getting the first chunk of text that should be considered. If that task is difficult in FOP, and you wish to defer it, you can probably safely do so by sending the space character 0x20 to the FontServer.selectFontXSL method. Most, if not all, fonts will be able to encode that character. There are some user issues that result from the new conformity, WRT simulating small-caps. The small-caps simulation logic that FOray inherited from FOP had the following features: 1. Used a hard-coded 80% figure. 2. The decision to use small-caps at all, always simulated, was made entirely outside of the font system. 3. Actual simulation of small-caps took place outside of the font system. In order to build a conformant font selection, items 1 and 2 above have been pulled into the font system. The aXSL font configuration DTD now includes for the font-description element an attribute called simulate-small-caps, which takes a percentage. Existence of the simulate-small-caps attribute also allows the font-description to be selected for either font-variant=normal or font-variant=small-caps requests. User must now provide a simulate-small-caps attribute for small-caps simulation to even be considered in the font-selection process. The font-selection logic should pick a true small-caps variant before picking one that merely simulates small-caps. Also the following method has been added to the Font interface to expose the new information provided in font configuration: public int smallCapsSize(int fontSize); This method returns the fontSize that should be used for intrinsically lowercase characters. Remember that the font system doesn't know when small-caps simulation is actually being used (item 3 above). It only knows whether it can be used or not, and, if so, the scaling factor that should be applied. BTW, the DTD now also includes the following font-description attributes: simulate-oblique CDATA #IMPLIED simulate-backslant CDATA #IMPLIED simulate-ultra-condensed CDATA #IMPLIED simulate-extra-condensed CDATA #IMPLIED simulate-condensed CDATA #IMPLIED simulate-semi-condensed CDATA #IMPLIED simulate-semi-expanded CDATA #IMPLIED simulate-expanded CDATA #IMPLIED simulate-extra-expanded CDATA #IMPLIED simulate-ultra-expanded CDATA #IMPLIED These are intended for aXSL implementation that wish to simulate font-style and font-stretch values. I have documented these pretty heavily in the DTD itself for those who want more detail. Victor Mote
font-selection-strategy
FOP-devs: WRT font-selection-strategy, I think the new aXSL methods provide the means to client applications to implement the character-by-character option. My current reading of the spec is that the auto option is merely an opportunity, a hook if you will, for an implementation to do something fancier than character-by-character. This whole attribute is actually an extension to CSS, which only does character-by-character. The definition of auto is The selection criterion given by the contextual characters is used in an implementation defined manner. That seems to cover almost anything doesn't it? Including character-by-character. The Note under auto seems to confirm this. Nevertheless, the example given in the Note provides some ideas for other algorithms, and seems to suggest that there is room for more than one. So, the general framework would seem to include the definition of one or more such algorithms, naming each one, and then providing that name through some global-ish mechanism like a font-configuration file or other configuration option. The font system can then implement the algorithm, perhaps with the help of call-back methods to provide, for example, the various pieces of contextual text. Now, I suggest that the creation and definition of such algorithms should be driven by the user base. IOW, if a user wishes to suggest an algorithm for font-selection that provides something useful to them, it should be considered. I say this partly because I don't seem to have a need for any such thing. My general approach is going to be to provide a list of exactly one font-family and then (by perusing the log!!) make sure that font-family actually got used. If it did not, I'm going to consider my stylesheet to be deficient as opposed to the font selection algorithm. In other words, I am going to implement my own manual algorithm. The other wrinkle that the standard seems to present is qualitative judgments like better quality fonts and match each other badly stylistically. I know of no way to get this information other than asking the user for it. So it is likely that some algorithms will require additional information in font-configuration. This post does not require any response from anyone. I realize you are trying to get a release out the door. I just wanted to document my thoughts on the matter for you before they escaped. Victor Mote
RE: FOrayFont, PS/PDFTranscoders and SVG handling
Jeremias Maerki wrote: For the drawString() methods we can create simple plug-ins much like the TextElementBridges which are called by the drawString() methods. Two implementations of the plug-in interface: One to paint using the new font subsystem and one that uses the Java2D font subsystem which should probably paint the text as shapes. The latter implementation can be done later when necessary as Batik paints all text through the TextBridge as far as I could see. For the DocumentGraphics2D classes can simply be subclassed to add font subsystem-specific code. PSDocumentGraphics2D and PSTranscoder can be removed entirely IMO. EPS should be enough for all cases, I think. The only use case for the PSTranscoder I can think of is for SVG Print, but that's easily done later again if someone really needs it again. ... What about the pdf library? That's the big question mark for me. The PDF library should be made as font subsystem agnostic as much as possible, so Batik can use the PDF library without a mandatory dependency on FOrayFont. I haven't investigated any details here, yet. The same point obviously apply for the PS generation code of which mainly PSFontUtils has a reference on the font subsystem. At least, PostScript will be a lot easier to handle than PDF. AFAICT, making the PDF library font-system-agnostic will require either 1) abstractions within it that must be implemented different ways within the package itself depending on the font system, or 2) some abstraction of the font system itself that would allow different font systems to be used by the same PDF library code, without the PDF code knowing which font system implementation it uses. Option 2 strikes me as being infinitely more sensible, and is the motivation for the axslFont interface. FWIW, the FOrayPDF package (as well as all other FOray packages) are written to the axslFont interface instead of the FOrayFont implementation. So, it is easy to avoid dependency on FOrayFont if you don't mind a dependency on axslFont. That might seem a trivial distinction. But I know of no other font system abstraction. Otherwise I would have strongly considered using it instead of creating axslFont. Don't forget that java.awt.Font can be wrapped inside any org.axsl.font.Font implementation. In fact, if it is wrapped inside, the java.awt.Font itself is exposed here: /** * If this Font has a java.awt.Font associated with it, return it. * @param consumer The [EMAIL PROTECTED] FontConsumer} implementation that is * requesting the AWT Font. * @param fontSize The font size, in millipoints. * @return The related [EMAIL PROTECTED] java.awt.Font} instance, if there is one, * otherwise null. */ public java.awt.Font getAWTFont(FontConsumer consumer, int fontSize) ; The only place I am a little concerned is in the font-configuration side of things within the FOrayFont implementation. It may be that more work is needed in font-registration to make sure that Batik gets the wrapped AWT font instead of some FreeStandingFont. Right now font-configuration can be configured to only register SystemFonts (AWT) or only register FreeStandingFonts, or to register both. If more work is needed there, I will need to rely on you guys to tell me what you need. Writing to the aXSL interface would allow a simple implementation that only created wrapped AWT fonts, if that were important. Also, it may be of interest to know that the FOrayFont implementation is pretty close to being able to marry FreeStandingFonts with SystemFonts. When configured this way, the AWT font is created from a font file on disk, using the same configuration options that allow FreeStandingFonts to be read from disk now. For those wishing to use only AWT fonts (like Batik and Folio), this allows them to then embed the font in an output document if they want to. For Java 1.3 and Java 1.4, only TTF fonts can be created this way. Java 1.5 also supports Type1 fonts. HTH. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Jeremias Maerki wrote: BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? PDF was derived from PostScript, so yes, they are well-defined. There is a group of so-called Base-35 fonts for PostScript that is a superset of the Base-14 fonts. I was always under the impression that PostScript implementations were required to support them just as PDF Renderers are required to support the Base-14. However, I am currently under the impression that the Base-35 is more of a convention than a standard, so it may not be quite as well-defined, but it is probably reasonable to assume that they are there. If the current approach is very difficult to implement, then I think it's best to use the approach with the renderer hint. IIUC, the current approach is to define all fonts that are registered and to embed all that are not Base-14. That is not too difficult to implement, but I think Vincent's point was that it seemed wrong. It would not be too hard to add a method that provides a collection of all registered fonts, but the Font objects returned must actually be parsed, which could be a lot of wasted overhead. The question would be whether that should be a standard aXSL method or whether it should be viewed as a hack that would just require an extension to FOrayFontServer. Since I gather that FOP will not be supporting the reuse of a FontServer instance (i.e. each document will have its own instance of FontServer), perhaps it works fine to just have the user provide a separate font-configuration file that contains only the fonts needed for the document. I can implement that for you if you want. Only referring to the font name will not work since we currently have to reencode each font to the WinAnsi charset. And since each PostScript page should be self-sufficient and removable, we can't do this reencoding when the font appears for the first time. Actually, you are no longer tied to WinAnsi. We have a lot more flexibility on encodings than before: 1. All of the predefined encodings for both PostScript and PDF are available to either platform -- of course, if they are not predefined for the platform used, they must be written into the output. 2. Both platforms have access to the font's internal encoding. 3. The user can specify custom encodings through the font-configuration file. So, if a PostScript document can use the font's internal encoding, and if the font is known to already be available to the interpreter, I think it could safely be used by name. But perhaps I have forgotten something. This may require a new font-configuration item for the font element that allows it to tell whether it is known to be available to the PostScript interpreter. There are some other possibilities here as well. Anyway, there are some more options for you to consider. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Vincent Hennebert wrote:
OK. That makes sense. To avoid wasteful parsing, it will
mean that at
least
3 new classes need to be exposed through interfaces
(RegisteredFont,
RegisteredFontFamily, and RegisteredFontDesc), which may be a good
thing anyway.
Yes, I think it could be interesting. It would also be
necessary to add getStream methods, now that font parsing is
delegated to the font server.
Currently there is only one getPDFFontFileStream method.
There should perhaps be also a getPSFontFileStream, and
something like getPDF/PSSubset? It seems that the client is
unable to make font subsetting with the current interface.
OK. I have actually not been sure how much of the code is reusable between
the two. PS rendering is way lower on my priority list than PDF, so I don't
work with it much. Here is our decision tree:
if (PS font embedding works in FOP now) {
if (it been added since May, 2004, when I forked the FOP code) {
we need to patch FOray with that logic;
} else {
Victor somehow lost this in the refactoring work;
FOray still needs to be patched;
}
} else {
we can add PS font embedding later;
}
I am not sure what you mean getPDF/PSSubset.
The more I think about it, encapsulating the
characteristics of a specific
PostScript interpreter is probably the right way to go.
Then the rendering
run can use that to decide whether the font needs to be
embedded or not.
I'll have to ponder that for awhile.
Here I'm beginning to get lost because I don't know the
Postscript standard.
My hope to get ready before the upcoming realease starts
vanishing... :-(
Here's my summary of the current discussion:
1. Currently the Fop PSRenderer embeds all of the configured
fonts in the PS
file, even those that will never be used. It does this by
parsing itself the
font files;
Hmmm. I think something has changed here since I last looked at it.
Jeremias?
2. I can't reproduce this behavior with aXSL and FOray
easily, because I've no
direct access to the font files;
Point me to the FOP code that does the embedding, class name(s) and line
numbers, and I'll see if I can extract it into an aXSL-exposed method.
3. Still doing this would require hacking the FOrayFont
subpackage; that would
result in something dirty but that should work;
Better would be to just make aXSL provide what needs to be provided. If we
can hack FOray to do it, then we should be able to expose what is needed.
Since nothing we are talking about here is a pollution of the interface, we
should just be able to change the interface.
4. Anyway there are several improvements to bring to the PS
renderer: mainly
character encoding, font embedding and in a longer term
two-pass rendering for a
proper font handling.
OK. I am confused. I thought above that font embedding worked in PS now, but
this seems to indicate that it does not.
Now I'm thinking of the next release: simply putting the font
name in the
postscript file would be rather straightforward to implement,
and should work
for most of cases (?), thanks to the non-standard but
well-known base14 (and
even base35) font set. But that's definitely a regression
from the current state.
Improving the PS renderer to allow proper embedding will
require (1) changes to
the aXSL interfaces (so a certain amount of discussions),
(2) me to learn
Postscript. That would prevent the FOrayFont subsystem from
being integrated in
the pre-release.
Do you agree with my summary?
I can take some of this burden off of you, in that I can hopefully fix aXSL
and FOray to provide what is needed. If that is done well, you shouldn't
need to learn too much PostScript to get it to work, and perhaps one of the
other developers can help you get it glued in. I don't know how much work it
will take for me to get the FOray PS Renderer working (it may work now), I
can use that as a test bed also.
Even if we can't get PS embedding working in time for the release (and I
think we should be able to), I am not sure whether this is a step backwards
from 0.20.5. I can't imagine that I just totally yanked PS embedding code
out of the FOray PS renderer.
Integrating FOrayFont in the pre-release would be great...
Deciding to delay the integration would give me more time to
investigate the
insides of FOrayFont, learn PS and PDF standards and so do
things much better.
If there is a decision to make it does not belong to me...
Vincent
Nor to me. I'll just try to help get working what you need and let you guys
decide what works best.
Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Jeremias Maerki wrote: And what about PCL? And SVG? And AFP? IMO, output format specific code should not appear in the main interfaces for font access. Every target platform will have their little specialities: special font formats, font conversions may be necessary (Type 1 to SVG fonts, SVG fonts to Type 3). It makes sense to write font embedding code directly in the renderer. The font provider can certainly make the job easier by providing access to often-used data and especially to the raw font streams. But that may be limited to certain aspects of a font type or dependant on the font subsystem implementation. Providing a font to a layout engine has also different requirements than embedding or using a font in a specific I agree with all of this, and this type of project is somewhere way down my mental to-do list. However, it requires more knowledge than I have of all of the various rendering possibilities to be able to factor out the lowest-common-denominator. The existing methods can best be thought of as workarounds. output format. Maybe the Font interface should simply have a method to return a very generic interface for more detailed and font- and output-system-specific access to the font. Consumers of this interface can then cast it to a special interface/class. Something like: TargetFormatHelper Font.getTargetFormatHelper(String mime) Subclasses of TargetFormatHelper could be PDFTargetFormatHelper or a PSTargetFormatHelper. The Font This is an interesting idea, but, if I understand it correctly, breaks pluggability. interface in aXSL seems to be overloaded already, so this might be an improvement anyway. I don't understand this comment. It is a high-level abstraction. Here's my summary of the current discussion: 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS file, even those that will never be used. It does this by parsing itself the font files; 2. I can't reproduce this behavior with aXSL and FOray easily, because I've no direct access to the font files; Which is a problem IMO. See my comments above. I *really* don't understand this. The whole point of the font subsystem is to hide as much detail as possible from the client application. If you want access to the raw font data, then perhaps the FOP 0.20.5 approach is better for what you need??!! 3. Still doing this would require hacking the FOrayFont subpackage; that would result in something dirty but that should work; I believe this can be designed in way that is even cleaner than it is now. I just wish I had time to participate but my priorities make that impossible. 4. Anyway there are several improvements to bring to the PS renderer: mainly character encoding, font embedding and in a longer term two-pass rendering for a proper font handling. Now I'm thinking of the next release: simply putting the font name in the postscript file would be rather straightforward to implement, and should work for most of cases (?), thanks to the non-standard but well-known base14 (and even base35) font set. Without the knowledge on how to access a glyph outside the default encoding, characters like the very important Euro character will be impossible to produce. Again, I am lost. The *only* way you get to characters outside the standard encoding is to specify a different encoding. We know how to do that. But that's definitely a regression from the current state. Improving the PS renderer to allow proper embedding will require (1) changes to the aXSL interfaces (so a certain amount of discussions), (2) me to learn Postscript. That would prevent the FOrayFont subsystem from being integrated in the pre-release. If aXSL-font provides access to the raw underlying font streams, that problem basically dissolves. The following would certainly be no problem: InputStream Font.getRawStream(String part) where part may be pfb, pfm, afm, ttf etc. Is this just for embedding purposes, or do you intend to parse it? If you want to parse it, why? If all you want to do is embed it, why do you want the metrics files? FOray essentially provides the raw font stream now. It works for PDF, but, if I understand Vincent correctly, does not work for PS. So how does this method you suggest help that? Do you agree with my summary? Integrating FOrayFont in the pre-release would be great... Quite unrealistic as it stands now, sorry. That is your (FOP's) decision, but it makes no sense to me. You are willing to go backwards in almost any other area, but are unwilling to *not* go forwards with PostScript font embedding? Even when it is doable? Still, I appreciate knowing. I'll shift my focus back to getting my FOray release out the door. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Jeremias Maerki wrote: I have recently implemented Type 1 embedding for those fonts which have the PFB file specified. Before that all Type 1 fonts were only referenced, their encoding redefined to WinAnsi and assigned a font key which is used inside the pages. OK. That should make it pretty easy for someone to patch FOray to do something similar. I'll get to it when I can. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Vincent Hennebert wrote: I am not sure what you mean getPDF/PSSubset. If I'm correct it is only possible to embed the whole font file in a pdf output, by using getPDFFontFileStream. Currently aXSL doesn't seem to provide a means to embed only a subset. OK. I understand. Yes, subsetting only works for TrueType fonts. I built a rudimentary PostScript interpreter that is currently only used for parsing some of the metrics out of PFA/PFB files, but which should eventually be able to help us subset Type 1 fonts. Point me to the FOP code that does the embedding, class name(s) and line numbers, and I'll see if I can extract it into an aXSL-exposed method. The whole code is in the class render.ps.PSFontUtil, mainly the method embedType1Font. Thanks, I'll work on that. Sorry, it also is a bit unclear to me. I think the precise status is the following: 1. font embedding only works with Type1 font for which a pfb file is provided (or also a pfa?). Subsetting --provided that this is specified by the postscript standard-- does not work; 2. currently only the WinAnsi charset seems to be supported. Fonts are systematically reencoded to this charset OK, that is consistent with what Jeremias said. I understand where FOP is now. I can take some of this burden off of you, in that I can hopefully fix aXSL and FOray to provide what is needed. If that is done well, you shouldn't need to learn too much PostScript to get it to work, and perhaps one of the other developers can help you get it glued in. I don't know how much work it will take for me to get the FOray PS Renderer working (it may work now), I can use that as a test bed also. I appreciate your offer to help! Today I quickly launched the FOray PS Renderer but it doesn't seem to work. I haven't investigated, though, this may be a minor problem. I think you may have the honor of being the first person to ever use it :-) I'll see if I can get it working at some basic level. Victor Mote
RE: PSDocumentGraphics2D and Font dictionary
Vincent Hennebert wrote: Integrating FOrayFont in the pre-release would be great... Quite unrealistic as it stands now, sorry. That is your (FOP's) decision, but it makes no sense to me. You are willing to go backwards in almost any other area, but are unwilling to *not* go forwards with PostScript font embedding? Even when it is doable? Still, I appreciate knowing. I'll shift my focus back to getting my FOray release out the door. Victor, from a non-native speaker POV you seem to be a bit overreacting here. I have the feeling that I have misled you because of my bad understanding of the problem. I'm sorry if this is the case. Jeremias has a better vision of the situation than me, and I quite agree with him that the integration won't be ready for the pre-release. This does not mean that it will never be done. And after all, all the better: we will have more time to discuss about a clean API. You didn't mislead me at all, nor did you do anything else wrong. On the contrary, I appreciate your efforts greatly. WRT me overreacting, perhaps I have been misunderstood. The font system works well enough for what FOray needs ATM, but there are a lot of other things that don't. I have rearranged my priorities to try to make sure that I am not a bottleneck on any of this for FOP. I guess this made it higher on my priority list than it was on FOP's, which is pretty stupid. So, having now a better understanding of where everyone else's priorities are, I am glad for the opportunity to adjust mine back to where they really ought to be anyway: FOray. P.S.: that said, the PDFRenderer should now work fine with the new font system; converting the SVG library should be pretty easy; this basically works for the AWT viewer. Nothing perfect, but... ;-) That is good news, and I think you should be applauded for your efforts here. Victor Mote
FOray contacts
FOP devs: I think it is prudent for me to take this temporary lull to extricate myself a bit more by unsubscribing from the fop-dev mailing list. I have tried to do this several times before, with little success, as you can see. I have no projects underway and no feuds to tend to ATM, so it is a rare (unique really) opportunity. I hope no one will misinterpret the timing or motivation. I am not mad at anyone. On the contrary I feel at peace with everyone still active. I do think my time and yours will be better spent without me being involved here. There are legitimate things that need to be discussed between our two projects, but those are really FOray issues, not FOP issues, so it will clean things up a bit to get those conversations moved to a more appropriate forum. Vincent is already active on the foray-developer mailing list, and all other interested parties are welcome as well. Links to the various FOray mailing lists can be found on these pages: http://www.foray.org/app/using/start.html http://www.foray.org/dev/index.html If replies are made to recent posts that require a response from me, please just cc: me in them. I'll resubscribe temporarily if I need to. I congratulate all of you on your upcoming release, and wish you all the best. Victor Mote
