Re: Incremental vs rewrite
Clay Leeds [EMAIL PROTECTED] schrieb am 19.05.2004 01:03:19: It would be interesting to compare some RenderX example output between the two^H^H^H three (ArndFO, fop-0.20.5, fop-1.0Dev)... I suspect there may be other significant differences as well, with performance, heap, etc. Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Then again, the more I think about it, the more it seems like Peter's train-of-thought RE: FOP development destabilization. 'We' could be working on FOP development, but instead we're talking about Arnd's (and Victor's) development efforts (I have every reason to believe it is everything he says it is), and discussing how the grass may be greener on the other side of the fence. That's true. So let's all get back to work. 8-) From Peter's mail: The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. I don't think what I did proves your point. Even though it worked for me this time, it was a high risk (ok, since I was always prepared to treat this a fun project, no risk). It was really a gamble, one I wouldn't have done under other circumstances - for example not if producing an FO formatter had been our business then. I suppose when you look around, you will find much, much more failed rewrite projects than failed incremental projects. In any case, I really don't think you can compare a one-person effort to that of a distributed group. Also, I believe this is rather a generic software-development question. If you think you do see the light at the end of the tunnel for the FOP rewrite then by all means go for it. There's one thing I want to mention at this point: The market (make that community if you prefer) for FO formatting is still very small. Growing, but still very small. The more different solutions that we see, the better for the market or community (yes, only to a certain extent of course). I am sure, even within the open source community, many users would be grateful not to be locked into using FOP, but to have an alternative. My 2 cents, but now finally back to work. Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
Re: cyrillic
Chris Bowditch wrote: Baron Moenghausen wrote: Hello! What wrong with pdf made with cyrillic KOI8-r? Hello, sorry but I dont understand your question. Could you rephrase it and maybe elaborate. Thanks, Chris OK, let's try again :) Imagine, I've made a pdf document with fop using CID-keyed fonts. The text is readable, but when I attempts to cut'n'paste into OpenOffice (or Word, so on) I have just instead of correct cyrillic text. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support.
Re: ANN: FOray
Victor Mote wrote: Simon Pepping wrote: I sympathize with this goal as well. I realize that that is not quite in line with my reaction to Glen's recent patch. I agree with Chris and Glen that it is not currently a key goal for FOP. And since we do not have a strong proponent and architect of a modular design, there is little point in leaving bits and pieces in the code. But in the longer run, I consider putting the FOP code in a modular structure as a desirable thing. If you guys are as close to having LayoutManager working as has been stated in this thread (and I hope you are), then I agree that modularization would not be the top priority. It is not an end in itself, but a means to an end. When FOP was internally forked 2 1/2 years ago, the only thing that needed to be rewritten from scratch was layout, but the whole project was forked instead. Modularization would have prevented that, and allowed releases to continue even though a chasm was being created and filled simultaneously. The whole nature of refactoring anything is that you do it before you do the real work. That is where FOray starts. That decision 2.5 years ago has cost FOP dearly. It is also much easier to see in hindsight. Given where FOP is today, I just want to see the last 5 issues fixed/implemented and we can do a release and get FOP back on track. The real question on modularity was never whether it should be a priority, but whether it hurt the project. On open-source projects, priorities are really set by each individual. You fix the thing that hurts the most at the moment, and that might be different for each developer. If I am working on A, and you are working on B, as long as your work on B isn't bad for the project as a whole, I have no right to complain. Nobody has yet put forth a good argument against modularization, but it was opposed anyway. So now we'll have a chance to test it in the real world. I dont recall modularizarion being opposed. It was more a case of Joerg saying it would be a challenge and no one else stepping up to support your proposals. From my point of view this was mainly due to me thinking FOPs priority is to get the last few bits of layout done so a release is possible. I'm certainly not against modularization, I think it would be beneficial, but would prefer to see effort going into finishing layout at this time. Once weve done an initial release from the development code, then modularization will be a more attractive proposal. Generally you are right in what you say that priorities are down to individuals. But given the situation FOP is currently in, I hope most people can see why I think No.1 priority is to finish layout. Consider this -- what if the XSL spec hadn't been split into two pieces? Would the part that we call Xalan today have its development stalled because layout is stalled? If XSL-T and XSL-FO were all in one spec, would we be smart enough to break the implementation into the two projects that it is in today? All we are really talking about here is the principle of encapsulation writ large. Modularization is in general a good idea, I just think its not the right time to be doing this within FOP. Perhaps modularization should have been done 2.5 years ago before branching the project. Chris
Justification and line breaking
Hi all I am still thinking about justification and the more general problem of line-breaking, and I have come to think that it's quite strange that the LineLayoutManager should make choices about breaking points using only the information provided by the TextLayoutManagers, while it should have a wider knowledge of all the text. (I see bug 28706 as an example of this strangeness: the LLM wants the TLM to say if there is other text after the returned BreakPoss, but the TLM doesn't know of the other TLMs' text) At the moment, lines are built one at a time, and in normal cases only underfull lines are taken into account: as both bpDim and availIPD have .min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen one is simply the last short BP returned by a TLM. Even if bpDim had .min != .max, the choice would be made between a few alternatives for the current line, without considering what will happen next; this could generate an output alternating tight and loose lines, which is not very beautiful. So, I have tried to implement Knuth's line-breaking algorithm [1], which calculates breaking points after having gathered information about a whole paragraph. Here are a few advantages of this algorithm: - first of all, the output is very beautiful; there is not a big difference in width between spaces in consecutive lines, and the max space width is smaller than before - the interaction between LLM and TLM is quite the same; the TLM returns a different kind of objects, much smaller - the TLM code is simplified a bit, as it has no more to handle leading spaces, or calculate flags (which IMO are rather line-related than text-related) - the LLM now can quite easily handle properties such as text-indent, text-align-last, word-spacing and letter-spacing Could I open a bugzilla issue and attach a patch? It would be quite a raw patch, as I took some short cuts to make it work and there could be some useless variables, anyway it works and could be used to show the quality of the output. I have tested it with text-only blocks, so I don't know what could happen in more complex situations. Regards Luca [1] D. E. Knuth and M. F. Plass, Breaking paragraphs into lines; I found this essay in D. E. Knuth, Digital typography, published by CSLI Publications
Re: Justification and line breaking
Luca, Do you know of a web-accessible version of the paper, or summary of the algorithm? Peter Luca Furini wrote: Hi all I am still thinking about justification and the more general problem of line-breaking, and I have come to think that it's quite strange that the LineLayoutManager should make choices about breaking points using only the information provided by the TextLayoutManagers, while it should have a wider knowledge of all the text. (I see bug 28706 as an example of this strangeness: the LLM wants the TLM to say if there is other text after the returned BreakPoss, but the TLM doesn't know of the other TLMs' text) At the moment, lines are built one at a time, and in normal cases only underfull lines are taken into account: as both bpDim and availIPD have .min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen one is simply the last short BP returned by a TLM. Even if bpDim had .min != .max, the choice would be made between a few alternatives for the current line, without considering what will happen next; this could generate an output alternating tight and loose lines, which is not very beautiful. So, I have tried to implement Knuth's line-breaking algorithm [1], which calculates breaking points after having gathered information about a whole paragraph. Here are a few advantages of this algorithm: - first of all, the output is very beautiful; there is not a big difference in width between spaces in consecutive lines, and the max space width is smaller than before - the interaction between LLM and TLM is quite the same; the TLM returns a different kind of objects, much smaller - the TLM code is simplified a bit, as it has no more to handle leading spaces, or calculate flags (which IMO are rather line-related than text-related) - the LLM now can quite easily handle properties such as text-indent, text-align-last, word-spacing and letter-spacing Could I open a bugzilla issue and attach a patch? It would be quite a raw patch, as I took some short cuts to make it work and there could be some useless variables, anyway it works and could be used to show the quality of the output. I have tested it with text-only blocks, so I don't know what could happen in more complex situations. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: ANN: FOray
Arnd Beißner wrote: Peter B. West [EMAIL PROTECTED] wrote on 19.05.2004 00:12:41: I think you are talking about different modularisation contexts here. You might want to clarify this part of the discussion with Victor. I really thought it was about the pluggable layout that Victor brought up a long time ago. If not, just forget what I said. 8-) You are correct that LayoutStrategy, aka pluggable layout was at the heart of the topic. And Peter is correct that the scope of modularization in LS was at a different level than you were talking about. But I don't understand Peter's point at all. If separation of concerns between page layout and block layout is beneficial, then how much more so that neither of them should be embedded in the FOTree??!! (Which FOP developers decided to redo just last week). The fact that you are successfully modularizing trees into branches and leaves is no argument against FOP modularizing the forest into trees. Victor Mote
RE: ANN: FOray
Chris Bowditch wrote: I dont recall modularizarion being opposed. It was more a case of Joerg saying it would be a challenge and no one else stepping up to support your proposals. When I left the project, there were 5 active developers, 1 for, 2 against, 2 neutral or silent. Joerg and I never disagreed on the difficulty of the project, and it was not an impediment to me that others were busy doing other things. But when active opposition emerged, it was time to cut bait. This is all water under the bridge, and I only mention it because you challenged my assertion. If FOray has any success at all, you all will have another opportunity to address the issue. Victor Mote
Re: Incremental vs rewrite
[EMAIL PROTECTED] wrote: Clay Leeds [EMAIL PROTECTED] schrieb am 19.05.2004 01:03:19: It would be interesting to compare some RenderX example output between the two^H^H^H three (ArndFO, fop-0.20.5, fop-1.0Dev)... I suspect there may be other significant differences as well, with performance, heap, etc. Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... Then again, the more I think about it, the more it seems like Peter's train-of-thought RE: FOP development destabilization. 'We' could be working on FOP development, but instead we're talking about Arnd's (and Victor's) development efforts (I have every reason to believe it is everything he says it is), and discussing how the grass may be greener on the other side of the fence. That's true. So let's all get back to work. 8-) From Peter's mail: The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. I don't think what I did proves your point. Even though it worked for me this time, it was a high risk (ok, since I was always prepared to treat this a fun project, no risk). It was really a gamble, one I wouldn't have done under other circumstances - for example not if producing an FO formatter had been our business then. I suppose when you look around, you will find much, much more failed rewrite projects than failed incremental projects. In any case, I really don't think you can compare a one-person effort to that of a distributed group. Also, I believe this is rather a generic software-development question. If you think you do see the light at the end of the tunnel for the FOP rewrite then by all means go for it. That's interesting. My view on alt.design has pretty much always been one talented guy working on the other side of the world, and coding FOP the way he always wanted to. No distractions or lengthy discussion (albeit frequently contributing insightful posts to FOP-Dev -user). I haven't been keeping tabs on the status of alt-design lately so I don't 'know' where it is at present (I'll check the status page directly). Web Maestro Clay
Re: Justification and line breaking
Luca Furini wrote: I am still thinking about justification and the more general problem of line-breaking, and I have come to think that it's quite strange that the LineLayoutManager should make choices about breaking points using only the information provided by the TextLayoutManagers, while it should have a wider knowledge of all the text. (I see bug 28706 as an example of this strangeness: the LLM wants the TLM to say if there is other text after the returned BreakPoss, but the TLM doesn't know of the other TLMs' text) bug 28706 is still a bit of mystery to me, well at least the disappearing text, as I dont have an example of it. At the moment, lines are built one at a time, and in normal cases only underfull lines are taken into account: as both bpDim and availIPD have .min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen one is simply the last short BP returned by a TLM. Even if bpDim had .min != .max, the choice would be made between a few alternatives for the current line, without considering what will happen next; this could generate an output alternating tight and loose lines, which is not very beautiful. So, I have tried to implement Knuth's line-breaking algorithm [1], which calculates breaking points after having gathered information about a whole paragraph. Here are a few advantages of this algorithm: - first of all, the output is very beautiful; there is not a big difference in width between spaces in consecutive lines, and the max space width is smaller than before - the interaction between LLM and TLM is quite the same; the TLM returns a different kind of objects, much smaller - the TLM code is simplified a bit, as it has no more to handle leading spaces, or calculate flags (which IMO are rather line-related than text-related) - the LLM now can quite easily handle properties such as text-indent, text-align-last, word-spacing and letter-spacing Could I open a bugzilla issue and attach a patch? It would be quite a raw patch, as I took some short cuts to make it work and there could be some useless variables, anyway it works and could be used to show the quality of the output. I have tested it with text-only blocks, so I don't know what could happen in more complex situations. this sounds like a really good idea, and would be very pleased if you could open a new bug in bugzilla and attach your patch. It will probably need a lengthy review involving plenty of testing and cleaning up. Chris
Re: Incremental vs rewrite
Clay Leeds wrote: Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... My understanding is that thanks to the property work earlier this year by Glen, Finn and Simon, that properties are 95% there, including shorthands. Admittely I didnt follow their work very closely, so could be wrong about this. Im sure Glen will interject and correct me on this if I'm wrong. snip/ Chris
Re: Incremental vs rewrite
Chris Bowditch wrote: Clay Leeds wrote: Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... My understanding is that thanks to the property work earlier this year by Glen, Finn and Simon, that properties are 95% there, including shorthands. Admittely I didnt follow their work very closely, so could be wrong about this. Im sure Glen will interject and correct me on this if I'm wrong. snip/ Chris Thanks for the update. I must've missed that part. I'll wait a bit for clarification (although it would probably be a good exercise for my XSLT skills...) Web Maestro Clay
DO NOT REPLY [Bug 28706] - [PATCH] More justification problems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28706. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28706 [PATCH] More justification problems --- Additional Comments From [EMAIL PROTECTED] 2004-05-19 18:39 --- 1. See XSL-PR/slice7.html#suppress-at-line-break, whose default value is 'auto'. Block.handleWhiteSpace cannot handle this because it runs at the refinement stage. 2. This point is about code level. When you take a step back, you cannot see the point.
Just do it (was: Re: Borders on Blocks)
Guys, my comment on this is: Commit it if you think it's an improvement. It may be a bit different if it concerned design questions, but with small fixed and improvements I'd rather you guys just did it. If it turns out to be a mistake it can easily be corrected. That's why we have peer review here. You guys block yourselves with this strategy and Arnd gets even more of a head-start. :-) On 18.05.2004 12:40:07 Chris Bowditch wrote: It fixes my problem, but I'll wait for any comments before committing this change. Jeremias Maerki (shutting up again)
DO NOT REPLY [Bug 29099] New: - pdf images does not appear in https
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29099. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29099 pdf images does not appear in https Summary: pdf images does not appear in https Product: Fop Version: 0.15 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I am using xsl-fo to generate a pdf and the images do not appear if I use https though they work fine with http. I work on Windows2K . When I try to get the version of XSL-FO using org.apache.fop.apps.Version.getVersion() I get it as null. I would like to know is FOP is SSL-compliant or I need a later version or any other thing that I am missing out on. Its very urgent and any help offered is appreciated. Thanks, Deepa
Re: Justification and line breaking
On Wed, May 19, 2004 at 12:08:50PM +0200, Luca Furini wrote: Hi all So, I have tried to implement Knuth's line-breaking algorithm [1], which calculates breaking points after having gathered information about a whole paragraph. Here are a few advantages of this algorithm: - first of all, the output is very beautiful; there is not a big difference in width between spaces in consecutive lines, and the max space width is smaller than before - the interaction between LLM and TLM is quite the same; the TLM returns a different kind of objects, much smaller - the TLM code is simplified a bit, as it has no more to handle leading spaces, or calculate flags (which IMO are rather line-related than text-related) - the LLM now can quite easily handle properties such as text-indent, text-align-last, word-spacing and letter-spacing Wow. No question that this is a desirable thing to have. I thought that it would be several releases away before we could address this. But if you have a viable solution, by all means show it to us. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Incremental vs rewrite
On Wed, May 19, 2004 at 04:34:14PM +0100, Chris Bowditch wrote: Clay Leeds wrote: Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... My understanding is that thanks to the property work earlier this year by Glen, Finn and Simon, that properties are 95% there, including shorthands. Admittely I didnt follow their work very closely, so could be wrong about this. Im sure Glen will interject and correct me on this if I'm wrong. That was basic work. The basis of the property subsystem is good, and shorthands all work, I think. But it is another question which properties are really implemented w.r.t. their effect on the layout. I do not think we have a good overview. See Glen's experimental approach: Transform a set of documents and see what you think is not right, which is the best we seem to be able to do right now. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Just do it (was: Re: Borders on Blocks)
Jeremias Maerki [EMAIL PROTECTED] schrieb am 19.05.2004 20:38:37: You guys block yourselves with this strategy and Arnd gets even more of a head-start. :-) 8-) -- Arnd Beißner Cappelino Informationstechnologie GmbH
Trait.ID_AREA
Hi guys, Inprevious versions (builds) of FOP areas have had set ID_AREA trait in order to allow identification of original FONodes (and XML elements) they had been created from. Why is this feature missing in recent builds (1.0DEV)? Is there any other possibility how to connect Area -- FONode -- XML Element data entities? Thanks Tibor Vyletel
Re: Incremental vs rewrite
Chris Bowditch wrote: Clay Leeds wrote: Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... My understanding is that thanks to the property work earlier this year by Glen, Finn and Simon, that properties are 95% there, including shorthands. Admittely I didnt follow their work very closely, so could be wrong about this. Im sure Glen will interject and correct me on this if I'm wrong. I do get burned when the work on properties is mentioned without any acknowledgment of the influence that alt-design has had on HEAD's properties development. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Clay Leeds wrote: [EMAIL PROTECTED] wrote: Clay Leeds [EMAIL PROTECTED] schrieb am 19.05.2004 01:03:19: It would be interesting to compare some RenderX example output between the two^H^H^H three (ArndFO, fop-0.20.5, fop-1.0Dev)... I suspect there may be other significant differences as well, with performance, heap, etc. Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... Shorthands have been fully handled in alt-design's properties for about 18 months now. Then again, the more I think about it, the more it seems like Peter's train-of-thought RE: FOP development destabilization. 'We' could be working on FOP development, but instead we're talking about Arnd's (and Victor's) development efforts (I have every reason to believe it is everything he says it is), and discussing how the grass may be greener on the other side of the fence. That's true. So let's all get back to work. 8-) From Peter's mail: The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. I don't think what I did proves your point. Even though it worked for me this time, it was a high risk (ok, since I was always prepared to treat this a fun project, no risk). It was really a gamble, one I wouldn't have done under other circumstances - for example not if producing an FO formatter had been our business then. I suppose when you look around, you will find much, much more failed rewrite projects than failed incremental projects. In any case, I really don't think you can compare a one-person effort to that of a distributed group. Also, I believe this is rather a generic software-development question. If you think you do see the light at the end of the tunnel for the FOP rewrite then by all means go for it. That's interesting. My view on alt.design has pretty much always been one talented guy working on the other side of the world, and coding FOP the way he always wanted to. No distractions or lengthy discussion (albeit frequently contributing insightful posts to FOP-Dev -user). I haven't been keeping tabs on the status of alt-design lately so I don't 'know' where it is at present (I'll check the status page directly). That won't do you much good, as I haven't updates the docs for some time now. I'm currently working on layout, using Java's facilities (including 1.3 and 1.4) for the layout engine. I'll update the pages as I make progress on this. Btw, I'm now in the dark about the way the web pages are being maintained. It's been a while since I was involved in the discussions about Forrest and FOP, primarily around using Javascript in pages. I'll read the docs docs again. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Java text handling
Do any of the list denizens have experience with Java font handling and 2D text layout? I'm new to it, and would like to be able to bounce questions off someone further up the food chain, on or off-line. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Incremental vs rewrite
Peter B. West wrote: Clay Leeds wrote: Be warned that the RenderX testsuite files require a relatively high degree of spec compliance. Shorthands are used everywhere, all table examples require auto-layout, and so on. I confess that I learned a few more things about FO when testing with these files... Sounds like a good exercise for someone like me, to transform those shorthand items into 'longhand'... Shorthands have been fully handled in alt-design's properties for about 18 months now. Glad to hear it! One of these days, I'll have to build alt.design from source so I can see all of your hard work. I notice that it uses a non-ant system of building, so I may get back to you on how steps to proceed with the build (unless the steps are outlined and/or linked from the site :-)). That's true. So let's all get back to work. 8-) From Peter's mail: The thing that immediately strikes me about Arnd's development is that it seems to blow away the theory that incremental modification of an existing code base is always the better way to go. IIUC, Arnd wrote a formatter from scratch (except for some fo the font handling) in two years. I don't think what I did proves your point. Even though it worked for me this time, it was a high risk (ok, since I was always prepared to treat this a fun project, no risk). It was really a gamble, one I wouldn't have done under other circumstances - for example not if producing an FO formatter had been our business then. I suppose when you look around, you will find much, much more failed rewrite projects than failed incremental projects. In any case, I really don't think you can compare a one-person effort to that of a distributed group. Also, I believe this is rather a generic software-development question. If you think you do see the light at the end of the tunnel for the FOP rewrite then by all means go for it. That's interesting. My view on alt.design has pretty much always been one talented guy working on the other side of the world, and coding FOP the way he always wanted to. No distractions or lengthy discussion (albeit frequently contributing insightful posts to FOP-Dev -user). I haven't been keeping tabs on the status of alt-design lately so I don't 'know' where it is at present (I'll check the status page directly). That won't do you much good, as I haven't updates the docs for some time now. I'm currently working on layout, using Java's facilities (including 1.3 and 1.4) for the layout engine. I'll update the pages as I make progress on this. Heh! I noticed that... I was actually going to ask if you had any updates I could apply, but then... Btw, I'm now in the dark about the way the web pages are being maintained. It's been a while since I was involved in the discussions about Forrest and FOP, primarily around using Javascript in pages. I'll read the docs docs again. Peter No problem. I think this is something *I* can handle... ;-) I recently spent some time figuring out Forrest. I haven't completed all of my travels, however, as I still get errors when I do a forrest run. However, I do understand the format itself pretty well, so if you can give me 'before' and after (or a diff would be fine, I can commit the necessary changes--committership has its privileges... don't worry, I won't touch JAVA code 'til I've spent some time hashing things through!) Otherwise, you could always just edit the XML source files the way you like. That should work just as well. Once the edits have been committed, running forrestbot should do the rest (of course we'll have to replace breadcrumb.js--D'oh!--as I think it still gets clobbered when forrestbot runs). Web Maestro Clay
Re: Java text handling
Peter B. West wrote: Do any of the list denizens have experience with Java font handling and 2D text layout? I'm new to it, and would like to be able to bounce questions off someone further up the food chain, on or off-line. Peter My experience has more to do with JRE and FONT handling, rather than what you probably want. Suffice it to say, that when you're doing testing use either IBM JRE 1.3.x+ or Sun JRE 1.4.0_b09+ as the AWT component of earlier versions have significant, sporadic font kerning issues. PDF/Postscript appears to be OK, though. Web Maestro Clay
Re: Incremental vs rewrite
Clay Leeds wrote: Peter B. West wrote: Shorthands have been fully handled in alt-design's properties for about 18 months now. Glad to hear it! One of these days, I'll have to build alt.design from source so I can see all of your hard work. I notice that it uses a non-ant system of building, so I may get back to you on how steps to proceed with the build (unless the steps are outlined and/or linked from the site :-)). It now uses Ant, so building is pretty straightforward. That's something else that will need updating in the docs. Btw, I'm now in the dark about the way the web pages are being maintained. It's been a while since I was involved in the discussions about Forrest and FOP, primarily around using Javascript in pages. I'll read the docs docs again. Peter No problem. I think this is something *I* can handle... ;-) I recently spent some time figuring out Forrest. I haven't completed all of my travels, however, as I still get errors when I do a forrest run. However, I do understand the format itself pretty well, so if you can give me 'before' and after (or a diff would be fine, I can commit the necessary changes--committership has its privileges... don't worry, I won't touch JAVA code 'til I've spent some time hashing things through!) Otherwise, you could always just edit the XML source files the way you like. That should work just as well. Once the edits have been committed, running forrestbot should do the rest (of course we'll have to replace breadcrumb.js--D'oh!--as I think it still gets clobbered when forrestbot runs). I'll send you diffs and refer any questions I have to you. Thanks Clay. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
