RE: Showing FO output
A year and a half ago we started to do something like that for a client ( we were even planning to ship an installer with a JRE bundled ), until they went out of bussines :(. But yesterday due to a mail from Keiron in replay to 'forrest is coming( fop logo )' I fished out of my HD some artwork ( splash screen and logo ) we were planning to use for the project. You can see some images @ http://www.manoamano.dk/FOP/ . mvh Ronald -Original Message- From: Oleg Tkachenko [mailto:olegt;multiconn.com] Sent: 6. november 2002 18:06 To: [EMAIL PROTECTED] Subject: Re: Showing FO output Jeremias Maerki wrote: I'm going a step further and I'm thinking about providing a development tool for FOP. We've developed a simple one at work where we could specify either FO or XML/xSLT file and an output format (FO, PDF, PS etc.). Then we have that big Process button that runs the document through Xalan and FOP. The configuration is saved when you exit, but at the moment we don't have multiple profiles. I've got a few good ideas about an improved tool in this direction. It would also be a good project for someone who'd like to contribute to the FOP project but doesn't want to go to the depths. I can elaborate if anyone is interested. I agree with you, I was thinking about it too. btw, I found an interesting mail in the xsl-list archive back to 1999 from James Tauber about his vision of FOP's future[1]: To give a little insight into my *long term* vision for FOP. Eventually, I would like to put a GUI interface on top to allow exactly this kind of human fine-tuning. The FOP engine does an initial layout and then a human can override line/column/page breaks, hyphenation, kerning, etc., saving back as formatting objects again. Well, but 1.0dev certanly is higher in the task list. [1] http://www.biglist.com/lists/xsl-list/archives/199905/msg00504.html -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/dev book.xml extensions.xml
keiron 2002/11/07 00:15:01 Modified:src/documentation/content/xdocs book.xml src/documentation/content/xdocs/dev book.xml extensions.xml Added: src/documentation/content/xdocs/design architecture.xml areas.xml book.xml breakpos.xml embedding.xml extending.xml fotree.xml index.xml layout.xml optimise.xml properties.xml renderers.xml status.xml useragent.xml Log: converted design docs to forrest needs updating Revision ChangesPath 1.5 +11 -3 xml-fop/src/documentation/content/xdocs/book.xml Index: book.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/book.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- book.xml 4 Nov 2002 16:20:51 - 1.4 +++ book.xml 7 Nov 2002 08:15:01 - 1.5 @@ -13,32 +13,40 @@ menu-item label=Download href=download.html/ menu-item label=Release Notes href=relnotes.html/ menu-item label=Getting Help href=gethelp.html/ + menu-item label=Examples href=examples.html/ +/menu +menu label=Project menu-item label=Status href=status.html/ menu-item label=Changes href=changes.html/ menu-item label=Todo href=todo.html/ +/menu +menu label=Using FOP menu-item label=Running href=running.html/ menu-item label=Embedding href=embedding.html/ menu-item label=Output Formats href=output.html/ menu-item label=Implemented href=implemented.html/ menu-item label=Limitations href=limitations.html/ +/menu +menu label=Extras menu-item label=SVG href=svg.html/ menu-item label=Extensions href=extensions.html/ menu-item label=Fonts href=fonts.html/ menu-item label=Configuration href=configuration.html/ +/menu +menu label=Developing menu-item label=Getting Involved href=involved.html/ menu-item label=Compiling href=compiling.html/ menu-item label=Testing href=testing.html/ +/menu +menu label=Resources menu-item label=Bugs href=bugs.html/ menu-item label=Resources href=resources.html/ menu-item label=License href=license.html/ - - menu-item label=Examples href=examples.html/ - external label=Patch queue href=http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Fopamp;short_desc=%5BPATCH%5Damp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;namedcmd=Fop+allamp;newqueryname=fop+patch+queueamp;tofooter=1amp;order=Reuse+same+sort+as+last+time/ /menu /book 1.1 xml-fop/src/documentation/content/xdocs/design/architecture.xml Index: architecture.xml === ?xml version=1.0 standalone=no? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN document-v11.dtd document header titleArchitecture/title subtitleArchitecture information for FOP/subtitle authors person name=Arved Sandstrom email=/ /authors /header body section titleFOP Mechanics/title section titleIntroduction/title p The overall process is controlled by emorg.apache.fop.apps.Driver/em. This class handles the FO Tree building, renderers, output and logging. /p p The process in general is that the FO document is sent to the tree builder via SAX events. This creates an FO Tree. The FO Tree is then handled by the layout processor which converts the FO Tree into an area tree. This area tree is then given to the renderer and the renderer converts the area tree into a stream of data containing the output document. /p /section section titleFormatting Object Tree/title p The class emorg.apache.fop.fo.FOTreeBuilder/em is responsible for actually constructing the FO tree. The key SAX events used are /p pcodestartElement()/code,/p pcodeendElement()/code and codecharacters()/code./p pAll formatting objects derive from abstract class emorg.apache.fop.fo.FONode/em. The other FO classes inherit from emFONode/em as follows:/p
Re: cvs commit: xml-fop/src/org/apache/fop/viewer/resources Viewer.propertiesViewer_cs.properties Viewer_de.properties Viewer_fi.properties Viewer_fr.propertiesViewer_it.properties Viewer_ja.properties Viewer_pl.properties Viewer_ru.properties
[EMAIL PROTECTED] wrote: keiron 2002/11/06 23:44:58 Modified:src/org/apache/fop/viewer/resources Viewer.properties Viewer_cs.properties Viewer_de.properties Viewer_fi.properties Viewer_fr.properties Viewer_it.properties Viewer_ja.properties Viewer_pl.properties Viewer_ru.properties Log: fixed line endings It's ok now. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[VOTE] Oleg for committer
Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
On Thursday 07 November 2002 09:23, Keiron Liddle wrote: Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! +1 - welcome! -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, Cocoon, FOP, mentoring/teaching/coding. blogspace http://www.codeconsult.ch/bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Forrest questions
Joerg, Keiron, et al: I want to add my congratulations for the good work on the new web site. It not only looks good, but loads noticeably faster on my connection. I also see (and like) the dev tab. As I understand it, the web site will eventually be updated daily automatically. This raises the question in my mind of how we (or any other project for that matter) will handle the differences between released versions and versions under development. Right now, for example, we have some doc that is basically for 0.20.4, and that we would want most users to find. However, we also have docs that are being updated frequently that are related to 1.0 (or the trunk or HEAD, if you will), which developers will want to find, and which those using cvs will want to find. I think it is useful to have both of these on our web site, perhaps on different tabs (??). Also, I have an html document that pulls together our Implemented and Limitations pages into one table with a column for each of the implementation compliance levels, color-coded to show what is complete and what is not. I did not see a DTD on the Forrest web site that fits this type of information. However, it looks like we can tell it not to validate certain documents. I'll be glad to convert it to XML with a stylesheet for HTML, or submit it as HTML. I'll also be glad to build and submit a DTD to Forrest, as this might be useful for other projects as well. I'm just not sure what is easier for you guys to deal with right now. What do you prefer? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Another Bugzilla URL
FOP Developers: Attached is another Bugzilla URL that I think is useful -- a list of all open items sorted by component. We may or may not want to put this on the web site -- many users find the front door to Bugzilla intimidating, and this may help them more readily find out whether the issue they are concerned about has already been reported. I haven't figured out how to eliminate [PATCH] entries from this list, but that might be a useful enhancement. BTW, I haven't found any doc on the mozilla site to help in building these URLs. If anyone knows of some, I would be grateful. Also, if there are other similar links that you would like to see, I'll be glad to take a stab at them. (My apologies if this message posts twice -- I sent it from another email address a few minutes ago I think the mail server probably ignored it because of the email address, so I am resending). Victor Mote http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Fopshort_desc= short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=order=bugs.component - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another Bugzilla URL
On Thursday 07 November 2002 10:09, Victor Mote wrote: . . . BTW, I haven't found any doc on the mozilla site to help in building these URLs. If anyone knows of some, I would be grateful. . . . I don't think there's any other way than studying what the bugzilla query form sends when you submit it, maybe trying to remove parameters that have no effect to keep the URLs short. Bugzilla allows queries to be saved (per-user at least), you might be able to create a named query with the appropriate parameters and call it from a URL by giving only the query name (but I didn't try it). This would prevent those URLs from being too long, which might cause them to be broken by old browsers. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another Bugzilla URL
Bertrand Delacretaz wrote: Bugzilla allows queries to be saved (per-user at least), you might be able to create a named query with the appropriate parameters and call it from a URL by giving only the query name (but I didn't try it). This would prevent those URLs from being too long, which might cause them to be broken by old browsers. I just tried named query, it works this way: http://nagoya.apache.org/bugzilla/buglist.cgi?namedcmd=myquerycmdtype=runnamed But that obviously works only on per-user basis so I don't see any profit we can get here. I personally like another approach, I see bugzilla primary as database therefore it have to provide pure data, e.g. in rdf or rss format (and latest bugzilla builds do support that, but not nagoya.apache.org's one). And having data-oriented xml we could present it in any form we like, e.g. what about embedding buglist into forrest (I have no idea if it's possible though). -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
Keiron Liddle wrote: Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! +1 Welcome Oleg! Christian P.S. I was just thinking about this too ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
J.Pietschmann wrote: I think it would be prudent to follow the same for fo:external-graphics and fo:color-profile, on the ground that FOs may be rendered out of order and, even more important, it is not clear whether multiple renderings of an external graphic in a static content, table header/footer or a marker should result in multiple access to the source. Unfortunately, the spec doesn't even mention this issue. btw, what about raising the issue on xsl-editors? Definitely a lot of things are implied, but actually xsl spec says just nothing. - Caching images across renderings definitely is an issue too (think of the company logo in each page header in every document), but FOP shouldn't solve this. I imagine a SourceResolver interface which gets an URL and optional content type and returns a XMLReader/InputSource pair. In case of binary image formats the default implementation returns a null parser. People who want to cache images across renderings can implement their own resolver which can do the caching. The Cocoon crowd will certainly rejoice (no more memory leaks due to FOP caching, access to Cocoon caching and Cocoon internal pipelines and other advantages). Good idea, worth to be added to the feature request list in order not to be forgotten. - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. I don't get it a little bit, why error should be generated? What's wrong with reloading an image each time it's referenced? - Dynamic URLs. In order to achive this, we can extend the functions available in property expressions by concat() and page-number(). This one looks dubious for me. Can we add any new functions to the core library? Extension functions in different namespace like we used to in xpath are certanly not allowed in xsl as FunctionName here is NCName in contrast to QName in xpath. One more fault in the spec I think. :( -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
A big +1!!! On 07 Nov 2002 09:23:44 +0100 Keiron Liddle wrote: Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! Here's my vote: +1 Keiron. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wed, 06 Nov 2002 23:06:53 +0100 J.Pietschmann wrote: snip/ Conclusions and ideas so far: - FOP should cache external graphics during a rendering and by default clear the cache afterwards. ok. - Caching images across renderings definitely is an issue too (think of the company logo in each page header in every document), but FOP shouldn't solve this. I imagine a SourceResolver interface which gets an URL and optional content type and returns a XMLReader/InputSource pair. In case of binary image formats the default implementation returns a null parser. People who want to cache images across renderings can implement their own resolver which can do the caching. The Cocoon crowd will certainly rejoice (no more memory leaks due to FOP caching, access to Cocoon caching and Cocoon internal pipelines and other advantages). But the SourceResolver approach will only let you cache the binary representation of an image, quite often it still has to be decoded each time it is used, which costs CPU power. Right? - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. So, I may not be so far off the mark after all. - Dynamic URLs. In order to achive this, we can extend the functions available in property expressions by concat() and page-number(). I believe both would be welcome by many users for other purposes too (whether that't a good idea is another matter). One of the possible concerns are usually name clashes with future XSLFO extensions. Using prefixed identifiers like fox:concat() would be a solution, I'm somewhat uneasy with using XML namespace mechanisms within values for XML attributes. In fact, I think its abuse, but I can't offer much better ideas either. I think you've got me wrong what I meant with dynamic URLs. I called the URL dynamic if the same URL can deliver a different content with each call. For example something similar to your example: http://ts.com/get-time.cgi Each time the URL gets called it returns a different image showing a clock giving the current time. It's a problematic discussion, somewhat. We're talking about image caching but there are at least two separate kinds: - Caching of images inside one processing run (which I consider the renderer's duty to a certain degree. Of course, the layout engine has to determine the extents of the image before the renderer goes into action) - Caching of images over a longer time and between processing runs. I agree that a specialized SourceResolver is a good thing but I still wonder about the decoding work. I was primarily wondering about the second kind of caching, but the discussion went stringly towards the first kind. Anyway, I'm still somewhat unsure about all this. Maybe we have to set up a new page in Betrand's Wiki to create a little specification for the image caching. This would also help as a discussion base if we have to contact the XSL:FO WG as Oleg suggests. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
+1 Keiron Liddle wrote: Hi Developers, I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
Provided, of course, that he controls his CRCRs. Peter B. West wrote: +1 -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14349] New: - redesign awt viewer as embeddable viewer bean and application, which uses it
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14349. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14349 redesign awt viewer as embeddable viewer bean and application, which uses it Summary: redesign awt viewer as embeddable viewer bean and application, which uses it Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: awt renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] AWT Viewer should be redesigned as an embeddable viewer java bean and swing application, which uses this bean. This way we would encourage embedding of FOP into various GUI java applications and also we can make X-Smiles guys life easier. Suggested by Jeremias Maerki [EMAIL PROTECTED], see http://marc.theaimsgroup.com/?l=fop-userm=103659073325588w=2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
At 02:09 AM 11/6/02, you wrote: I just went looking in the archives for this discussion thought I saw pieces of it, but could not find what I was looking for -- namely, what theories you guys had proposed / agreed upon. This is related to the font work that I have started, i.e. I assume that the problem is a difference between metrics reported/used by the awt Font and those reported from our parsed metrics files. If it is not too much trouble, do you mind recapping a brief summary of where the issue stands now? Thanks. Victor (and Oleg, Keiron) I agree this should get summarized (and documented.) Presently, I am trying to systematically reproduce it here -- it may take another day or two, since the new JRE versions appear to behave differently (and still wrongly, it appears). -- And, frankly, I'm totally confused by what I'm seeing today. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HashMaps (WAS:RE: interface instead of implementation)
Well, we can get as detailed as people want. I just figured that, while we were throwing around ideas about what kind of programming paradigm and idioms we want, we may wish to consider using different kind of Reference objects or Collections that employ them (ala a WeakHashMap) in certain cases. Judiciously used WeakReferences can pay out in spades on memory usage, which can also mean a performance boost in processing time as the GC isn't running as freuqently. We could get more detailed in a discussion of this if you're interested, though...what aspects of Reference use did you want to discuss? -Original Message- From: Peter B. West [mailto:pbwest;powerup.com.au] Sent: Wednesday, November 06, 2002 6:55 PM To: [EMAIL PROTECTED] Subject: Re: HashMaps (WAS:RE: interface instead of implementation) Rhett, Jeremias, I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Peter Rhett Aultman wrote: Mostly it was for caching benefits. As I said, though, I haven't read enough code to know. I just thought I'd throw it out as a possibile way to save on memory usage when FOP processes large documents. *shrug* ;) -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
I didn't intend to kill that discussion with my response. I'm not a specialist on those Reference classes but I've heard enough to say that it can be tricky and should probably not be used just because it's sexy. I'd vote for not using them unless there is a real good reason. I'm not sure about your use case, but you might just have to do some research. I'm sorry not to be more of a help. Here's one URL describing the stuff in short. I'm sure there are better ones. http://developer.java.sun.com/developer/TechTips/1999/tt0511.html#tip2 On Thu, 07 Nov 2002 09:54:51 +1000 Peter B. West wrote: I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
References (WAS:RE: HashMaps)
I wasn't suggesting using them because they're sexy. Personally, I don't use Reference objects unless they can't be avoided. However, collections that use WeakReferences can be a serious help. Essentially, they can help ensure object cleanup in a more timely fashion than traditional techniques, as an object placed in, say, a WeakHashMap will automatically be garbage collected when the only reference to the object is in the WeakHashMap. It's a natural safeguard against someone forgetting to dereference an object in a Collection when they're done with it, which results in memory leakage. Again, not being a FOP code veteran, I don't know where the points of use might be, but Reference objects and the weak collections seem to be a part of the Java API that don't get much coverage, so I wasn't sure if anyone had even considered their use. -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] Sent: Thursday, November 07, 2002 8:51 AM To: [EMAIL PROTECTED] Subject: Re: HashMaps (WAS:RE: interface instead of implementation) I didn't intend to kill that discussion with my response. I'm not a specialist on those Reference classes but I've heard enough to say that it can be tricky and should probably not be used just because it's sexy. I'd vote for not using them unless there is a real good reason. I'm not sure about your use case, but you might just have to do some research. I'm sorry not to be more of a help. Here's one URL describing the stuff in short. I'm sure there are better ones. http://developer.java.sun.com/developer/TechTips/1999/tt0511.html#tip2 On Thu, 07 Nov 2002 09:54:51 +1000 Peter B. West wrote: I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14351] New: - It would be nice to allow FOP users to see xsl-fo sources.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14351. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14351 It would be nice to allow FOP users to see xsl-fo sources. Summary: It would be nice to allow FOP users to see xsl-fo sources. Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When FOP gets input as xml + xsl it may be useful for debuging or learning purpouses to see xsl-fo document. It can be implemented either as an additional output format or as View source feature of AWT Viewer. Requested by Leif Frederiksen [EMAIL PROTECTED], see http://marc.theaimsgroup.com/?l=fop-userm=103658571520765w=2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14352] New: - It would be nice if FOP could be plugged into popular xml/xsl editors.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14352. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14352 It would be nice if FOP could be plugged into popular xml/xsl editors. Summary: It would be nice if FOP could be plugged into popular xml/xsl editors. Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] XML Spy has a nice feature, which allows to run FOP on fo or xml files in one click. It would be nice to have such plugins for other widespread xml/xsl editors or IDE, e.g. for xemacs, JEdit, XMetal, eclipse, you name it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: References (WAS:RE: HashMaps)
On Thu, 2002-11-07 at 14:58, Rhett Aultman wrote: I wasn't suggesting using them because they're sexy. Personally, I don't use Reference objects unless they can't be avoided. However, collections that use WeakReferences can be a serious help. Essentially, they can help ensure object cleanup in a more timely fashion than traditional techniques, as an object placed in, say, a WeakHashMap will automatically be garbage collected when the only reference to the object is in the WeakHashMap. It's a natural safeguard against someone forgetting to dereference an object in a Collection when they're done with it, which results in memory leakage. The image caching actually uses the WeakHashMap in cvs. The idea is that during the creation of a document the image will be load then at some later time output. During this time it has a strong reference. Once the image is no longer needed by the renderer then it is placed into a weak hashmap, this may garbage collect if memory is needed (although I read somewhere that the jvm often gc's first time). If another document then needs the image it is recovered if available and strongly referenced until finished with that document. As for other parts of FOP, I haven't thought of any, usually it is a case of it is needed or not needed. Again, not being a FOP code veteran, I don't know where the points of use might be, but Reference objects and the weak collections seem to be a part of the Java API that don't get much coverage, so I wasn't sure if anyone had even considered their use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: feature request queue
Bertrand Delacretaz wrote: . . . Patch queue looks very good, and what about introducing one more queue for feature requests? . . . I think these can be identified by the severity=enhancement field of bugzilla issues, isn't that sufficient? Ok, here is URL (I'm not sure how to short it): http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_severity=Enhancementemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Fopshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnamedcmd=ffdnewqueryname=order=Reuse+same+sort+as+last+time It can be added as Enhancement queue into Todo page. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Forrest questions
On Thu, 2002-11-07 at 10:04, Victor Mote wrote: Joerg, Keiron, et al: I want to add my congratulations for the good work on the new web site. It not only looks good, but loads noticeably faster on my connection. I also see (and like) the dev tab. As I understand it, the web site will eventually be updated daily automatically. This raises the question in my mind of how we (or any other project for that matter) will handle the differences between released versions and versions under development. Right now, for example, we have some doc that is basically for 0.20.4, and that we would want most users to find. However, we also have docs that are being updated frequently that are related to 1.0 (or the trunk or HEAD, if you will), which developers will want to find, and which those using cvs will want to find. I think it is useful to have both of these on our web site, perhaps on different tabs (??). Some of these issues have been raised with forrest, but not answered as far as I know. The dev tab is actually meant to be the user etc. docs for 1.0dev, maybe a better name could be used. Also, I have an html document that pulls together our Implemented and Limitations pages into one table with a column for each of the implementation compliance levels, color-coded to show what is complete and what is not. I did not see a DTD on the Forrest web site that fits this type of information. However, it looks like we can tell it not to validate certain documents. I'll be glad to convert it to XML with a stylesheet for HTML, or submit it as HTML. I'll also be glad to build and submit a DTD to Forrest, as this might be useful for other projects as well. I'm just not sure what is easier for you guys to deal with right now. What do you prefer? With a stylesheet would probably be better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Oleg for committer
I suggest we have a vote for Oleg to be a committer. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
Jeremias, Rhett, I didn't realise that Reference objects were sexy, which seems to imply that was not my reason for being interested in them. Basically, Rhett, I was prompting for peoples' experiences, if any. Jeremias Maerki wrote: I didn't intend to kill that discussion with my response. I'm not a specialist on those Reference classes but I've heard enough to say that it can be tricky and should probably not be used just because it's sexy. I'd vote for not using them unless there is a real good reason. I'm not sure about your use case, but you might just have to do some research. I'm sorry not to be more of a help. Say I have a tree, one line of which looks something like this: +---+---+-+---+-...-+---+ +-+-| 0 | P | | C | | C | | | +---+---+-+---+-...-+---+ | |^ | | | || +--+ +--... | || | | || v | | +---+-+-+-+---+-...-+---+ | +--+-R | P | | C | | C | | +---+---+-+---+-...-+---+ | ^ | | | | +--+ +--... | | | | | v | +---+---+-+---+-...-+---+ +-+-R | P | | C | | C | +---+---+-+---+-...-+---+ | | +--+ +--... | etc., where C are the child references, P are the parent references and R are the root references, necessary in this case because the root of the FO tree has turned into a singleton with a lot of the common data used by properties and FO nodes. Instead of using direct references for the C and P pointers, I have been thinking vaguely about using some kind of indirect reference - type unknown as yet. Ignoring R pointers for now, if I want to cache a subtree, the Reference objects seem to offer the possibility of indicating that the caching is required, and leaving the actual caching operation until GC demands it. If the cached subtree is accessed in the meantime, it should be pushed to the end of the caching queue. If the memory is reclaimed, the Reference object is alerted, and arranges to do the actual caching, then converts itself to a different kind of indirect reference, one which, when normally accessed, will arrange to retrieve the cached subtree, and reestablish it as a pending. These things just sound interesting - sexy, even, now that you mention it - though I doubt their sex appeal was a strong motive for creating them. The raw documentation doesn't really give much of a feel for their potential. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/xml SyncedFoXmlEventsBuffer.java
pbwest 2002/11/07 07:30:50
Modified:src/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design
SyncedFoXmlEventsBuffer.java
Log:
Added getStartElement(BitSet, boolean) and
expectStartElement(BitSet, boolean) for processing of FO sets within
fo:page-sequence descendants.
Revision ChangesPath
No revision
No revision
1.1.2.2 +68 -2
xml-fop/src/org/apache/fop/xml/Attic/SyncedFoXmlEventsBuffer.java
Index: SyncedFoXmlEventsBuffer.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/xml/Attic/SyncedFoXmlEventsBuffer.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- SyncedFoXmlEventsBuffer.java 24 Oct 2002 14:39:11 - 1.1.2.1
+++ SyncedFoXmlEventsBuffer.java 7 Nov 2002 15:30:50 - 1.1.2.2
@@ -7,6 +7,7 @@
import java.util.NoSuchElementException;
import java.util.LinkedList;
import java.util.Iterator;
+import java.util.BitSet;
/*
* $Id$
@@ -749,6 +750,71 @@
// Found it!
if (ev != null) return ev;
}
+return null;
+}
+
+/**
+ * Get one of a ttBitSet/tt of possible STARTELEMENT events. Scan
+ * and discard events until a STARTELEMENT event is found which is in
+ * the fo: namespace and whose FO type matches one of those in the
+ * argument ttBitSet/tt.
+ * @param set a ttBitSet/tt containing FO types one of which is
+ * required.
+ * @param discardWhiteSpace - if true, discard any ttcharacters/tt
+ * events which contain only whitespace.
+ * @return the next matching STARTELEMENT event from the buffer.
+ * @exception FOPException if buffer errors or interrupts occur
+ * @exception NoSuchElementException if the event is not found
+ */
+public FoXMLEvent getStartElement(BitSet set, boolean discardWhiteSpace)
+throws FOPException
+{
+FoXMLEvent ev;
+do {
+ev = expectStartElement(set, discardWhiteSpace);
+if (ev != null) return ev;
+// The non-matching event has been pushed back.
+// Get it and discard. Note that if the first attempt to
+// getEvent() returns null, the expectStartElement() calls
+// will throw a NoSuchElementException
+ev = getEvent();
+} while (ev != null);
+// Exit from this while loop is only by discovery of null event
+throw new NoSuchElementException
+(StartElement from BitSet not found.);
+}
+
+/**
+ * Expect one of an ttBitSet/tt of possible STARTELEMENT events.
+ * The next STARTELEMENT must be in the fo: namespace, and must have an
+ * FO type which matches one of those in the argument ttBitSet/tt.
+ * pTODO:br
+ * This method should be retro-fitted to list and array versions.
+ *
+ * @param set a ttBitSet/tt containing the FO types
+ * of possible events, one of which must be the next returned.
+ * @param discardWhiteSpace - if true, discard any ttcharacters/tt
+ * events which contain only whitespace.
+ * @return the matching STARTELEMENT event.If the next
+ * event detected is not of the required type, ttnull/tt is returned.
+ * The erroneous event is pushed back.
+ * @exception FOPException if buffer errors or interrupts occur
+ * @exception NoSuchElementException if end of buffer detected.
+ */
+public FoXMLEvent expectStartElement
+(BitSet set, boolean discardWhiteSpace)
+throws FOPException
+{
+FoXMLEvent ev;
+ev = expectTypedEvent(XMLEvent.STARTELEMENT, discardWhiteSpace);
+if (ev == null) return ev;
+
+for (int i = set.nextSetBit(0); i = 0; i = set.nextSetBit(++i)) {
+if (ev.foType == i)
+return ev; // Found it!
+}
+// Not found - push the STARTELEMENT event back
+pushBack(ev);
return null;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14356] New: - *NOT* embedding TrueTypeFont in PDF causes AcrobatReader displaying only dots
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14356. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14356 *NOT* embedding TrueTypeFont in PDF causes AcrobatReader displaying only dots Summary: *NOT* embedding TrueTypeFont in PDF causes AcrobatReader displaying only dots Product: Fop Version: 0.20.3 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When creating PDFs using non-standard fonts we have to create the metric file and configure the userconfig.xml. I did so with embed-file=... set in the font metrics file and everything worked fine. Now I omitted the embed- file=... statement and created a new PDF-file based on the same XSL and XML files. The result is not really nice, only dots appear in the PDF file (viewed in Acrobat Reader). Also the font properties of the _correct_ PDF file are quite unusual: Instead of embedding a TrueType font FOP embeds a TrueTypeCID font using Identity-H-coding instead of Windows-coding. So, how can I get FOP embedding a TrueTypeFont in Windows coding __OR__ what do I have to do that the created PDF can be viewed correctly without embedding the font? (The font is available on the system where the PDF is viewed). MM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HashMaps (WAS:RE: interface instead of implementation)
Something like what you're describing might be doable with SoftReference objects. Basically, you could consider a SoftReference to be much like a regular reference except that, whereas the GC must respect regular references at all times, it's allowed to ignore SoftReferences when it's trying to free memory. The guarantee is that SoftReferences will be broken before memory runs out (whereas, of course, regular ones aren't). JVMs can do as they want with them (regarding the choice to reclaim or not) the rest of the time, but I don't think they're particularly aggressive on them. In this case, if your pointers were SoftReferences, then everything would be in a GC-enforced expirable cache. If a subtree is accessed prior to the GC reclaiming it, the accessing body would contain a hard reference to it. The hard reference trumps the soft one, so the subtree is now safe from collection until the hard reference is released. If the subtree's children should be held on to at this time, then it will need to hold hard references to them as well. The biggest issue in working with References is in analyzing how the part of the program using SoftReferences will interact with the rest of the program. An entire chunk of your program can use regular references internally, but if that chunk is softly referred to the rest of the program, the entire chunk can be GCed as needed. Using hard references internally in that subsystem, though, ensures that the entire subsystem is atomically GCed, whereas with soft references, anything could go at any time. This can be a complex and dicey issue, and I'd be happy to discuss it with you further, but maybe we should take the conversation off-line, since it doesn't seem to be FOP specific? -Original Message- From: Peter B. West [mailto:pbwest;powerup.com.au] Sent: Thursday, November 07, 2002 10:21 AM To: [EMAIL PROTECTED] Subject: Re: HashMaps (WAS:RE: interface instead of implementation) Instead of using direct references for the C and P pointers, I have been thinking vaguely about using some kind of indirect reference - type unknown as yet. Ignoring R pointers for now, if I want to cache a subtree, the Reference objects seem to offer the possibility of indicating that the caching is required, and leaving the actual caching operation until GC demands it. If the cached subtree is accessed in the meantime, it should be pushed to the end of the caching queue. If the memory is reclaimed, the Reference object is alerted, and arranges to do the actual caching, then converts itself to a different kind of indirect reference, one which, when normally accessed, will arrange to retrieve the cached subtree, and reestablish it as a pending. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: But the SourceResolver approach will only let you cache the binary representation of an image, quite often it still has to be decoded each time it is used, which costs CPU power. Right? I think so. But nevertheless that would be a cool feature. Consider such a real use case: one have image stored in an application jar file. At the moment I think FOP cannot handle such case, but having SourceResolver we can delegate source URI resolving to a user, like URIResolver does and one can easily return us kind of stream, e.g. new InputSource(getClass().getResourceAsStream(/path/to/foo.gif)) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Mailing List Woes?
Gang, Who here keeps tabs on mailing list administration? I have a frustrated user/developer who's trying to post to the list. He says he's subscribed to the list but now he's having trouble posting to it. Is there someone on here I could refer him to? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Mailing List Woes?
Rhett Aultman wrote: Who here keeps tabs on mailing list administration? I have a frustrated user/developer who's trying to post to the list. He says he's subscribed to the list but now he's having trouble posting to it. Is there someone on here I could refer him to? [EMAIL PROTECTED] ? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14356] - *NOT* embedding TrueTypeFont in PDF causes AcrobatReader displaying only dots
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14356. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14356 *NOT* embedding TrueTypeFont in PDF causes AcrobatReader displaying only dots --- Additional Comments From [EMAIL PROTECTED] 2002-11-07 17:51 --- I posted a message before about this issue. You need to re-encode your font files using the -enc ansi option for TTFReader. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: - Caching images across renderings But the SourceResolver approach will only let you cache the binary representation of an image, quite often it still has to be decoded each time it is used, which costs CPU power. Right? Right. Next try: provide a layered set of interfaces: - SourceResolver: resolves URI to XMLReader+InputSource. Used for, well, source resolving for graphics, color profiles, fonts, font metrics, perhaps config files, whatever. Can be hooked into for URI mapping, custom protocols, on the fly generation, simple caching. Default implementation similar to the common javax.xml.transform.URIResolver, with a few twists (must peek into the stream to check for XML unless forced by content type). - ImageResolver: resolves a URI+some properties (which?) into a FOPImage. Default implementation uses SourceResolver to get a stream and whether it is an XML stream, detects image type (unless forced by content type). Can be hooked into for advanced image caching (still call the default implementation for doing the image creation). - FontResolver: Same for fonts. - FontMetricsResolver: for completeness, or fold this into the FontResolver. - ColorProfileResolver, : Just to be complete, or use SourceResolver directly. - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. So, I may not be so far off the mark after all. Revised thoughts: Two control attributes - tentatively: fox:cache + yes (default): keep the FOPImageObject (for this rendering run) + no: discard it immediately after rendering. Use this to prevent large images which occure only once to take up memory indefinitely. Problem: how should this be handled in static content, markers, table headers/footers with omit-header-at-break=false? Perhaps discard with FO rather than discard after rendering? - tentatively: fox:access + once (default): do not access the source if it has already been accessed, if there is no cached FOPImage, raise an error + use-cached: do not access the source if there is a cached FOPImage, else reload + on-creation: access source while creating this FO unconditionally, replace cached image if there is one. + on-rendering: access source each time this FO is rendered. Don't ask me how this should work together with the resolver stuff above. Perhaps the fox:access stuff is overengineering, don't take it too serious. - Dynamic URLs. I think you've got me wrong what I meant with dynamic URLs. I got it quite right. I should have mentioned I wanted to supply a mechanism which allows the construction of different URIs in case someone wants to use images for page numbers. Maybe we have to set up a new page in Betrand's Wiki to create a little specification for the image caching. This would also help as a discussion base if we have to contact the XSL:FO WG as Oleg suggests. Neat idea. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Oleg Tkachenko wrote: - Fine tuning: A single large image will block a lot of memory during rendering. A possibility is a fox:cache=no control property. In order to preserve semantics, a null image is cached for this URL, and an error is generated in case it is attempted to render the image a second time. I don't get it a little bit, why error should be generated? What's wrong with reloading an image each time it's referenced? Because it breaks the (FOP) specified semantics that the image is always the same in case the source chooses to supply a different image on each access. But see the other post. - Dynamic URLs. In order to achive this, we can extend the functions available in property expressions by concat() and page-number(). This one looks dubious for me. Can we add any new functions to the core library? Can we? Sure. Is it wise to do so? Oh well, get me an asbestos suit quickly! Extension functions in different namespace like we used to in xpath are certanly not allowed in xsl as FunctionName here is NCName in contrast to QName in xpath. One more fault in the spec I think. :( Oops! I didn't notice this. Didn't someone on the XML-DEV list recently mention they prepare for a 2.0? Seems they have to do a lot of home work for this! BTW changing NCName - QName is probably considered an incompatible change, warranting a new release... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Oleg Tkachenko wrote: I think so. But nevertheless that would be a cool feature. Consider such a real use case: one have image stored in an application jar file. At the moment I think FOP cannot handle such case, I didn't try myself, but a jar URI should work. Something like jar:file:///foo/bar.jar#com/experanto/images/logo.gif Sorry, I'm too lazy to look up details. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Oleg for committer
Keiron Liddle wrote: I suggest we have a vote for Oleg to be a committer. If Oleg accepts then he can get on with making FOP great! Here's my vote: +1 Me too! +1 J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
Rhett, Thanks for this. Rhett Aultman wrote: This can be a complex and dicey issue, and I'd be happy to discuss it with you further, but maybe we should take the conversation off-line, since it doesn't seem to be FOP specific? Not for now - this is percolating in the back of the mind - but I'll remember the offer. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow package.html
pbwest 2002/11/07 15:18:17 Added: src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design package.html Log: Package description. Revision ChangesPath No revision No revision 1.1.4.1 +6 -0 xml-fop/src/org/apache/fop/fo/flow/Attic/package.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoFlow.java FoPageSequence.java FoStaticContent.java FoTitle.java
pbwest 2002/11/07 15:19:54 Added: src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design FoFlow.java FoPageSequence.java FoStaticContent.java FoTitle.java Log: Initial checkin of elements for fo:page-sequence. Revision ChangesPath No revision No revision 1.1.2.1 +86 -0 xml-fop/src/org/apache/fop/fo/flow/Attic/FoFlow.java 1.1.2.1 +159 -0xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageSequence.java 1.1.2.1 +86 -0 xml-fop/src/org/apache/fop/fo/flow/Attic/FoStaticContent.java 1.1.2.1 +101 -0xml-fop/src/org/apache/fop/fo/flow/Attic/FoTitle.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FObjectSets.java
pbwest 2002/11/07 15:32:32 Added: src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FObjectSets.java Log: Sets of FOs as expressed in 6.2 Formatting Object Content. Revision ChangesPath No revision No revision 1.1.2.1 +124 -0xml-fop/src/org/apache/fop/fo/Attic/FObjectSets.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FOPropSets.java
pbwest 2002/11/07 15:54:46 Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FOPropSets.java Log: Moved property sets for fo:page-sequence, fo:title, fo:static-content and fo:flow to their respective FOs. Revision ChangesPath No revision No revision 1.1.2.4 +3 -33 xml-fop/src/org/apache/fop/fo/Attic/FOPropSets.java Index: FOPropSets.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FOPropSets.java,v retrieving revision 1.1.2.3 retrieving revision 1.1.2.4 diff -u -r1.1.2.3 -r1.1.2.4 --- FOPropSets.java 5 Nov 2002 14:22:45 - 1.1.2.3 +++ FOPropSets.java 7 Nov 2002 23:54:46 - 1.1.2.4 @@ -251,9 +251,6 @@ foPropertyLists[FObjectNames.FLOAT] = new ROBitSet(floatset); //flow -BitSet flow = new BitSet(); -flow.set(PropNames.FLOW_NAME); -foPropertyLists[FObjectNames.FLOW] = new ROBitSet(flow); //footnote BitSet footnote = new BitSet(); @@ -567,18 +564,6 @@ foPropertyLists[FObjectNames.PAGE_NUMBER_CITATION] = new ROBitSet(page_number_citation); //page-sequence -BitSet page_sequence = new BitSet(); -page_sequence.set(PropNames.COUNTRY); -page_sequence.set(PropNames.FORMAT); -page_sequence.set(PropNames.LANGUAGE); -page_sequence.set(PropNames.LETTER_VALUE); -page_sequence.set(PropNames.GROUPING_SEPARATOR); -page_sequence.set(PropNames.GROUPING_SIZE); -page_sequence.set(PropNames.ID); -page_sequence.set(PropNames.INITIAL_PAGE_NUMBER); -page_sequence.set(PropNames.FORCE_PAGE_COUNT); -page_sequence.set(PropNames.MASTER_REFERENCE); -foPropertyLists[FObjectNames.PAGE_SEQUENCE] = new ROBitSet(page_sequence); //page-sequence-master @@ -610,9 +595,6 @@ //single-page-master-reference //static-content -BitSet static_content = new BitSet(); -static_content.set(PropNames.FLOW_NAME); -foPropertyLists[FObjectNames.STATIC_CONTENT] = new ROBitSet(static_content); //table BitSet table = new BitSet(); @@ -793,18 +775,6 @@ foPropertyLists[FObjectNames.TABLE_ROW] = new ROBitSet(table_row); //title -BitSet title = new BitSet(); -title.or(PropertySets.accessibilitySet); -title.or(PropertySets.auralSet); -title.or(PropertySets.backgroundSet); -title.or(PropertySets.borderSet); -title.or(PropertySets.paddingSet); -title.or(PropertySets.fontSet); -title.or(PropertySets.marginInlineSet); -title.set(PropNames.COLOR); -title.set(PropNames.LINE_HEIGHT); -title.set(PropNames.VISIBILITY); -foPropertyLists[FObjectNames.TITLE] = new ROBitSet(title); //wrapper BitSet wrapper = new BitSet(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
