Re: FOP logo
Peter B. West wrote: I mentioned the need for a logo some months ago to an acquaintance of mine who is a graphics design student. She came up with some interesting ideas, but they were incomplete the last time I spoke to her (just before Christmas.) I will try to get in touch with her again, and get her to post some of her sketches for comment. Well, a jury is waiting :) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
On 12.01.2003 11:40:57 Bernd Brandstetter wrote: After having tried to understand how fop works by just reading the code for a couple of hours now, FOrtress inevitably comes to my mind ;-) (in the sense of: Not easy to get in, at least for a newbie) :-) Unfortunately, Fortress is already taken by the Apache Avalon project for one their new containers. I bet they wouldn't be happy to hear your association with the name. Let's be serious again: What do you think could be improved to make FOP easier to get in? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation skinconf.xml
jeremias2003/01/13 02:21:45 Modified:src/documentation skinconf.xml Log: Fixes DTD and enables FOP logo for PDF files. Submitted by: Jeff Turner [EMAIL PROTECTED] Revision ChangesPath 1.5 +10 -5 xml-fop/src/documentation/skinconf.xml Index: skinconf.xml === RCS file: /home/cvs/xml-fop/src/documentation/skinconf.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- skinconf.xml 11 Jan 2003 16:49:26 - 1.4 +++ skinconf.xml 13 Jan 2003 10:21:45 - 1.5 @@ -11,10 +11,14 @@ !ENTITY % links.att 'name CDATA #REQUIRED' !ENTITY % link.att 'name CDATA #REQUIRED href CDATA #REQUIRED' - !ELEMENT skinconfig (disable-search?, searchsite-domain?, searchsite-name?, project-name, project-url, project-logo, group-name?, group-url?, group-logo?, host-logo?, year?, vendor?, trail?, credits?)* + !ELEMENT skinconfig (disable-search?, searchsite-domain?, searchsite-name?, + project-name, project-url, project-logo, group-name?, group-url?, group-logo?, + host-url?, host-logo?, year?, vendor?, trail?, credits?)* !ELEMENT credits (credit*) - !ELEMENT credit (name, url, image, width?, height?) - !ATTLIST credit role CDATA #IMPLIED + !ELEMENT credit (name, url, image?, width?, height?) + !-- id uniquely identifies the tool, and role indicates its function -- + !ATTLIST credit id CDATA #IMPLIED + role CDATA #IMPLIED !ELEMENT disable-search (#PCDATA) !ELEMENT searchsite-domain (#PCDATA) !ELEMENT searchsite-name (#PCDATA) @@ -24,6 +28,7 @@ !ELEMENT group-name (#PCDATA) !ELEMENT group-url (#PCDATA) !ELEMENT group-logo (#PCDATA) + !ELEMENT host-url (#PCDATA) !ELEMENT host-logo (#PCDATA) !ELEMENT year (#PCDATA) !ELEMENT vendor (#PCDATA) @@ -90,12 +95,12 @@ width138/width height31/height /credit-- -!--credit role=pdf +credit role=pdf nameCreated by: FOP 1.0dev/name urlhttp://xml.apache.org/fop/dev/url imageimages/logo.jpg/image width138/width height31/height -/credit-- +/credit /credits /skinconfig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
On 12.01.2003 04:59:36 Jeff Turner wrote: On Sat, Jan 11, 2003 at 05:43:37PM +0100, Jeremias Maerki wrote: Hi Jeff I've applied your patches locally. Thanks. Everything's ok with the first one, but with the second one I'm having problems (not your fault!): - I had to add adjust the inline DTD of skinconf.xml to include the role attribute: !ELEMENT credit (name, url, image, width?, height?) !ATTLIST credit role CDATA #IMPLIED Oops yes, sorry. Attached is a fix with DTD mods. Applied, thanks. - The credit element produces a rather ugly FOP logo. If you upgrade your Forrest, the logo won't appear[1]. The @role=pdf in skinconf.xml means the credit only applies to PDFs. Earlier versions of Forrest didn't know about this, so rather than display a broken image, I threw in the current FOP logo. Ok, I've upgraded Forrest again and the logo disappeared. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Embedding documentation
Is it OK if I just throw out some usage patterns in the embedding documentation? There's some contradicting information there and also stuff that isn't that easy to understand. InputHandler and friends dates back to pre-JAXP times. JAXP is known to most users doing embedding and is most natural to work with. That's why I also implemented my embedding examples using JAXP. I'm not asking for deleting InputHandler and friends, only in the documentation. Altough I'd like to delete them in the redesign. But that's another story. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16017] New: - Jpeg's and the PDF Serializer
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=16017. 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=16017 Jpeg's and the PDF Serializer Summary: Jpeg's and the PDF Serializer Product: Fop Version: 0.20.4 Platform: Other URL: http://approveone.phaseone.com:8080/cocoon/mount/editee/ 2003011352.pdf OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This looks like a bug. I want to generate a .pdf document, using the XSL functions in cocoon. Works fine, but when i include an JPEG image, i get the image displayed with a Yellow filter apply to it. Experimenting with this, i tried converting the same image to different formats, the ones i found working was GIF and PNG. But not the same quality as the JPEG. Looks to me that the FOP is trying to convert the image to CMYK, but fails to do so. Is there somewhere i configure the FOP, or is a serious bug ? Im running on a Linux RH 7.2 dist , with tomcat 4.1.8, Cocoon 2.0.4. and j2sdk1.4.0 Submitted by. jacob Bager An-concepts.dk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16017] - Jpeg's and the PDF Serializer
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=16017. 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=16017 Jpeg's and the PDF Serializer --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 11:15 --- Please, provide sample of JPEG image to reproduce the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Embedding documentation
Jeremias Maerki wrote: Is it OK if I just throw out some usage patterns in the embedding documentation? There's some contradicting information there and also stuff that isn't that easy to understand. InputHandler and friends dates back to pre-JAXP times. JAXP is known to most users doing embedding and is most natural to work with. That's why I also implemented my embedding examples using JAXP. +0 I'm not asking for deleting InputHandler and friends, only in the documentation. Altough I'd like to delete them in the redesign. But that's another story. Lets discuss? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16017] - Jpeg's and the PDF Serializer
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=16017. 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=16017 Jpeg's and the PDF Serializer --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 11:31 --- additional info: the target pdf is http://approveone.phaseone.com:8080/cocoon/mount/editee/test.pdf the source is located at: http://approveone.phaseone.com/pdf/test.xml as the jpg, png, gif, picture is as well. http://approveone.phaseone.com/pdf/test.jpg (and for comparison:) http://approveone.phaseone.com/pdf/test.gif http://approveone.phaseone.com/pdf/test.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP compliance in XML?
Hi, Is there an XML version of the tables in http://xml.apache.org/fop/compliance.html? Alternatively, I'd be interested to have the compliance information (comments) merged into Chuck Paussa's FO/FOP schema. Either way, if nobody is doing it already, then I volunteer. Benoit Maisonny -- .. Benoit Maisonny[EMAIL PROTECTED] Director Consultant http://synclude.com Synclude Ltd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP compliance in XML?
Yes, see here: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/documentation/content/xdocs/compliance.xml?rev=1.5content-type=text/vnd.viewcvs-markup Volunteers are always welcome. :-) What exactly would you like to do with it? On 13.01.2003 12:52:29 Benoit Maisonny wrote: Hi, Is there an XML version of the tables in http://xml.apache.org/fop/compliance.html? Alternatively, I'd be interested to have the compliance information (comments) merged into Chuck Paussa's FO/FOP schema. Either way, if nobody is doing it already, then I volunteer. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP logo
Why don't we announce a competition. I've been thinking of writing to this list for a while to offer 'graphic' help to the project (My background is Art Design not CS) and would love to take part :-) regards Andy This e-mail and its attachments are confidential. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although ri3k Limited believes this e-mail and any attachments to be free of any virus or other defect which may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and ri3k Limited does not accept any responsibility for any loss or damage in any way from its use. ri3k Limited Registered in England: 10-12 Ely Place, London, EC1N 6RY Company Number: 3909745 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Output consideration 1.3 vs. 1.4
I've read the PDF/X FAQ and there seems to be more than only PDF/X-3. There are at least 5 standards. Scary thing. Anyway, I think it should be possible to make the PDF library configurable to generate PDF 1.3 only. But implementing even one of the PDF/X standards can't be a current topic for us comitters during this phase of the redesign. But if you like to contribute to this we're happy to apply patches you send. I've added this to our todo list here: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectTasks On 11.01.2003 19:32:03 Arnd Beißner wrote: Since you are currently discussing PDF 1.3 vs. 1.4 issues, there's one thing not all of you may be aware of: There's a relatively new standard called PDF/X-3. This is basically PDF 1.3 with a number of restrictions. Some can be handled by the user (all fonts must be embedded), some others must be adhered to by the PDF generator. The intention of PDF/X is to standardize on a PDF subset that can be handled without the usual problems in the prepress business (missing or mismatched fonts, color mismatches, trapping etc.). For more information see http://www.pdfx.info. There's also a freeware PDF/X preflight tool called PDF/X-3 Inspector (download URL: http://www.pdfx.info/download.html). The reason I'm mentioning this is that one of the restrictions of PDF/X-3 is that the PDF file may not be PDF 1.4 (I'm not sure if lower than 1.3 is ok). To pave the way for future PDF/X support, you may consider still supporting PDF 1.3 in the redesign code tree. At least perhaps make it configurable. Hope this information is useful. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16023] New: - tiff images are not rendered
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=16023. 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=16023 tiff images are not rendered Summary: tiff images are not rendered Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: awt renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] tiff images are not rendered in the awt viewer. they are rendered when i use pdf as output format, but not with awt. yes, jimi library support is compiled :-) is there a workaround for that? or a fix already? thanks, domenico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/servlet - New directory
jeremias2003/01/13 08:25:14 xml-fop/examples/servlet - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/servlet/conf - New directory
jeremias2003/01/13 08:25:47 xml-fop/examples/servlet/conf - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/servlet/lib - New directory
jeremias2003/01/13 08:25:55 xml-fop/examples/servlet/lib - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/servlet/src - New directory
jeremias2003/01/13 08:25:59 xml-fop/examples/servlet/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/servlet/src FopPrintServlet.java FopServlet.java
jeremias2003/01/13 08:27:14 Added: examples/servlet Tag: fop-0_20_2-maintain .cvsignore README build.bat build.sh build.xml examples/servlet/conf Tag: fop-0_20_2-maintain web.xml examples/servlet/lib Tag: fop-0_20_2-maintain servlet-2.2.jar servlet.LICENSE.txt examples/servlet/src Tag: fop-0_20_2-maintain FopPrintServlet.java FopServlet.java Log: Example Servlet moved over from contrib/servlet Revision ChangesPath No revision No revision 1.1.2.1 +1 -0 xml-fop/examples/servlet/Attic/.cvsignore 1.1.2.1 +21 -0 xml-fop/examples/servlet/Attic/README 1.1.2.1 +34 -0 xml-fop/examples/servlet/Attic/build.bat 1.1.2.1 +29 -0 xml-fop/examples/servlet/Attic/build.sh 1.1.2.1 +90 -0 xml-fop/examples/servlet/Attic/build.xml No revision No revision 1.1.2.1 +21 -0 xml-fop/examples/servlet/conf/Attic/web.xml No revision No revision 1.1.2.1 +127 -0xml-fop/examples/servlet/lib/Attic/servlet-2.2.jar Binary file 1.1.2.1 +59 -0 xml-fop/examples/servlet/lib/Attic/servlet.LICENSE.txt No revision No revision 1.1.2.1 +241 -0xml-fop/examples/servlet/src/Attic/FopPrintServlet.java 1.1.2.1 +138 -0xml-fop/examples/servlet/src/Attic/FopServlet.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/contrib/servlet/src FopPrintServlet.java FopServlet.java
jeremias2003/01/13 08:28:39 Removed: contrib/servlet Tag: fop-0_20_2-maintain .cvsignore README build.bat build.sh build.xml contrib/servlet/conf Tag: fop-0_20_2-maintain web.xml contrib/servlet/lib Tag: fop-0_20_2-maintain readme.txt contrib/servlet/src Tag: fop-0_20_2-maintain FopPrintServlet.java FopServlet.java Log: Example Servlet moved over to examples/servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] doc validation fix
Oleg Tkachenko wrote: I like it. First of all FOP is well-known among the whole xml community for ages (what costs much) and secondly fop word has a Yes, this is the primary consideration. The only reason why I mention it now at all is that changing such things is always better done sooner rather than later. Entry Word: fop Function: noun Text: a man who is conspicuously fashionable or elegant in dress or appearance felt contempt for the mincing overdressed fop Synonyms Beau Brummel, blood, buck, coxcomb, dandy, dude, exquisite, gallant, lounge lizard, macaroni, petit-maître, popinjay Related Word fashion plate, silk stocking; blade, cavalier, man-about-town, spark, sport, swell; ladies' man, lady-killer, masher Idioms man of the world I never have a problem writing it, but when speaking it, I cannot make my mouth say fop, but invariably say eff-oh-pee instead. May I ask why? (Sorry, after spending the whole day in the beach I'm a liitle bit stupid :) It must be a cultural thing. The dictionary definition you gave should tell the story well enough -- see the example felt contempt for the mincing The word is a pejorative, but perhaps more so in my part of the world, where calling someone a fop or a dandy might be fighting words. In my mind it connotes sissy on one end of the scale and big hat, no cattle on the other. This is all partially mitigated by the fact that the word is pretty much in disuse, so maybe nobody else knows what it means. Finding myself in the minority, I withdraw the question. I intended no offence. As a workaround, please don't be offended if I continue to treat the name as an acronym instead of a word. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/foschema - New directory
jeremias2003/01/13 08:35:13 xml-fop/src/foschema - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/foschema fop.xsd fop4f.xsd schema2completion.xsl schema2dtd.xsl
jeremias2003/01/13 08:35:58 Added: src/foschema Tag: fop-0_20_2-maintain fop.xsd fop4f.xsd schema2completion.xsl schema2dtd.xsl Log: Moved over from docs/foschema Revision ChangesPath No revision No revision 1.1.2.1 +4292 -0 xml-fop/src/foschema/Attic/fop.xsd 1.1.2.1 +4292 -0 xml-fop/src/foschema/Attic/fop4f.xsd 1.1.2.1 +197 -0xml-fop/src/foschema/Attic/schema2completion.xsl 1.1.2.1 +319 -0xml-fop/src/foschema/Attic/schema2dtd.xsl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/foschema fop.xsd fop4f.xsd schema2completion.xsl schema2dtd.xsl
jeremias2003/01/13 08:36:40 Removed: docs/foschema Tag: fop-0_20_2-maintain fop.xsd fop4f.xsd schema2completion.xsl schema2dtd.xsl Log: Moved over to src/foschema - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP compliance in XML?
Benoit Maisonny wrote: This looks perfect for my needs! I am working on an FO quick reference that includes compliance information for fop and xep. A couple of caveats: 1) The html version on our website is misleading because the color-coding is scrubbed out in our forrest conversion (I am trying to get that fixed). 2) The content applies to 0.20.5, not the main branch. 3) The content might not be entirely accurate. It came from some other documents, which I think were a bit out of date. It is really intended as a good starting place. In particular, I think there are places where we say that FOP is in compliance, but where there are some limitations that need to be cross-referenced. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
docs/xslfoRef.xml
Hi there There's a xslfoRef.xml containing a small reference for XSL-FO. An XSLT exists for converting the reference to FO. It still reflects the Candidate Recommendation, so it is outdated. Can I simply delete it or should I move it somewhere, too? It's the only thing left in the docs directory when I'm finished moving docs/examples to examples/fo. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo - New directory
jeremias2003/01/13 10:08:21 xml-fop/examples/fo - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/tables - New directory
jeremias2003/01/13 10:08:34 xml-fop/examples/fo/tables - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/svg - New directory
jeremias2003/01/13 10:08:39 xml-fop/examples/fo/svg - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/region_body - New directory
jeremias2003/01/13 10:08:43 xml-fop/examples/fo/region_body - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/pagination - New directory
jeremias2003/01/13 10:08:47 xml-fop/examples/fo/pagination - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/markers - New directory
jeremias2003/01/13 10:08:52 xml-fop/examples/fo/markers - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/keeps_and_breaks - New directory
jeremias2003/01/13 10:08:56 xml-fop/examples/fo/keeps_and_breaks - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/graphics - New directory
jeremias2003/01/13 10:09:01 xml-fop/examples/fo/graphics - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/footnotes - New directory
jeremias2003/01/13 10:09:06 xml-fop/examples/fo/footnotes - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/basic - New directory
jeremias2003/01/13 10:09:10 xml-fop/examples/fo/basic - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/advanced - New directory
jeremias2003/01/13 10:09:14 xml-fop/examples/fo/advanced - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: thoughts on fonts (was: text-decoration)
Jeremias Maerki wrote:
Can we sketch that on the Wiki in some simple way? Defining some Java
interfaces and things like that? Anyway, as you mentioned we should sort
out things like Session and Document on another page first.
OK, I just put a proposal out there in the section discussing Facade. More
on this below.
It would be great if you would read up on Avalon a bit.
I assume that we are talking about the Framework stuff here. I still haven't
found the ServiceManager that you mentioned.
Do I get you right that you would get something like that?
public interface Font {
String getFontName();
int getFontWeight();
int getFontSize();
FontMetrics getFontMetricsForLayout();
}
public interface FontMetrics {
//These methods already take font size into account
int getAscender();
int getDescender();
int getCapHeight();
//more...
int getWidth(char c);
boolean hasKerningAvailable();
//more...
}
That looks promising.
See the wiki where I have added a couple of things to your outline above.
The main difference is that I am not thinking of it as an interface, because
I only ever want one implementation. The concrete class is itself the
interface that the remainder of the system uses. My un-OOP (but not
anti-OOP) background is probably showing through here, so please talk me out
of this if I am out of line. The reason for my approach is that ideally,
what we might want here is for java.awt.Font to be in implementation of the
interface that we wish to use. That is not an option. So what we are
building is a /virtual/ interface that we can hide java.awt.Font and /all/
other font concepts behind. We are trying to find commonality between
objects that have similar real-world characteristics, but that have no
compiler-level common heritage. There may be a better way.
Yes, I share your unease, but I look at it from this side: Multiple area
trees mean possibly different layout which can be a problem when you're
working in an environment where you're working with legally relevant
documents. Two generated documents from the same source must be as equal
as possible. (funny use of equal, I know)
I guess what I am saying is that different fonts used will probably /force/
different area trees. So, from out standpoint, better to disallow it than to
disappoint.
Sorry to be so slow in responding.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/fo/tables background.fo borders.fo break.fo headfoot.fo keep.fo omit.fo space.fo widowsorphans.fo
jeremias2003/01/13 10:23:56 Added: examples/fo Tag: fop-0_20_2-maintain .cvsignore build.xml runtests.bat runtests.sh examples/fo/advanced Tag: fop-0_20_2-maintain cid-fonts.fo cid-fonts.pdf giro.fo test_ja.fo examples/fo/basic Tag: fop-0_20_2-maintain bgimage.fo border.fo bordershorthand.fo character.fo contlabel.fo corresprop.fo extensive.fo fonts.fo hyphen.fo images.fo inhprop.fo instream.fo leader.fo link.fo list.fo newlinktest.fo normal.fo normalex.fo pdfoutline.fo readme.fo simple.fo table.fo tableunits.fo textdeko.fo examples/fo/footnotes Tag: fop-0_20_2-maintain columns.fo simple.fo examples/fo/graphics Tag: fop-0_20_2-maintain fop.jpg linux.bmp listgeometry.gif page.gif xml_fax.tif xml_feather.gif xml_feather_transparent.gif examples/fo/keeps_and_breaks Tag: fop-0_20_2-maintain columnlevel1.fo pagelevel1.fo pagelevel2.fo pagelevel3.fo pagelevel4.fo examples/fo/markers Tag: fop-0_20_2-maintain glossary.xml glossary.xsl hide.fo examples/fo/pagination Tag: fop-0_20_2-maintain allregions.fo basic1.fo basic2.fo franklin_2pageseqs.fo franklin_alt.fo franklin_rep.fo franklin_rep_max_repeats.fo franklin_rep_max_repeats_expl.fo franklin_rep_max_repeats_nl.fo examples/fo/region_body Tag: fop-0_20_2-maintain simplecol.fo simplecol2.fo simplecol3.fo simplecol4.fo examples/fo/svg Tag: fop-0_20_2-maintain boxes.svg embedding.fo external.fo multi.svg ref.svg view.svg examples/fo/tables Tag: fop-0_20_2-maintain background.fo borders.fo break.fo headfoot.fo keep.fo omit.fo space.fo widowsorphans.fo Log: Moved over from docs/examples build.xml overhauled, generates all fo files from all directories except advanced Removed some warnings from certain fo files Revision ChangesPath No revision No revision 1.1.2.1 +3 -0 xml-fop/examples/fo/Attic/.cvsignore 1.1.2.1 +120 -0xml-fop/examples/fo/Attic/build.xml 1.1.2.1 +38 -0 xml-fop/examples/fo/Attic/runtests.bat 1.1.2.1 +55 -0 xml-fop/examples/fo/Attic/runtests.sh No revision No revision 1.1.2.1 +450 -0xml-fop/examples/fo/advanced/Attic/cid-fonts.fo 1.1.2.1 +561 -0xml-fop/examples/fo/advanced/Attic/cid-fonts.pdf Binary file 1.1.2.1 +1244 -0 xml-fop/examples/fo/advanced/Attic/giro.fo 1.1.2.1 +146 -0xml-fop/examples/fo/advanced/Attic/test_ja.fo No revision No revision 1.1.2.1 +46 -0 xml-fop/examples/fo/basic/Attic/bgimage.fo 1.1.2.1 +188 -0xml-fop/examples/fo/basic/Attic/border.fo 1.1.2.1 +169 -0xml-fop/examples/fo/basic/Attic/bordershorthand.fo 1.1.2.1 +105 -0xml-fop/examples/fo/basic/Attic/character.fo 1.1.2.1 +293 -0xml-fop/examples/fo/basic/Attic/contlabel.fo 1.1.2.1 +237 -0xml-fop/examples/fo/basic/Attic/corresprop.fo 1.1.2.1 +146 -0xml-fop/examples/fo/basic/Attic/extensive.fo 1.1.2.1 +224 -0xml-fop/examples/fo/basic/Attic/fonts.fo 1.1.2.1 +468 -0xml-fop/examples/fo/basic/Attic/hyphen.fo 1.1.2.1 +89 -0 xml-fop/examples/fo/basic/Attic/images.fo 1.1.2.1 +175 -0xml-fop/examples/fo/basic/Attic/inhprop.fo 1.1.2.1 +114 -0xml-fop/examples/fo/basic/Attic/instream.fo 1.1.2.1 +725 -0xml-fop/examples/fo/basic/Attic/leader.fo 1.1.2.1 +135 -0xml-fop/examples/fo/basic/Attic/link.fo 1.1.2.1 +2689 -0 xml-fop/examples/fo/basic/Attic/list.fo 1.1.2.1 +114 -0xml-fop/examples/fo/basic/Attic/newlinktest.fo 1.1.2.1 +149 -0xml-fop/examples/fo/basic/Attic/normal.fo 1.1.2.1 +149 -0xml-fop/examples/fo/basic/Attic/normalex.fo 1.1.2.1 +1411 -0 xml-fop/examples/fo/basic/Attic/pdfoutline.fo 1.1.2.1 +1341 -0 xml-fop/examples/fo/basic/Attic/readme.fo 1.1.2.1 +99 -0 xml-fop/examples/fo/basic/Attic/simple.fo 1.1.2.1 +504 -0
cvs commit: xml-fop/docs/examples/tables background.fo borders.fo break.fo headfoot.fo keep.fo omit.fo space.fo widowsorphans.fo
jeremias2003/01/13 10:29:13 Removed: docs/examples Tag: fop-0_20_2-maintain .cvsignore build.xml results.html runtests.bat runtests.sh docs/examples/advanced Tag: fop-0_20_2-maintain cid-fonts.fo cid-fonts.pdf giro.fo test_ja.fo docs/examples/fo Tag: fop-0_20_2-maintain bgimage.fo border.fo bordershorthand.fo character.fo contlabel.fo corresprop.fo extensive.fo fonts.fo hyphen.fo images.fo inhprop.fo instream.fo leader.fo link.fo list.fo newlinktest.fo normal.fo normalex.fo pdfoutline.fo readme.fo simple.fo table.fo tableunits.fo textdeko.fo docs/examples/footnotes Tag: fop-0_20_2-maintain columns.fo simple.fo docs/examples/keeps_and_breaks Tag: fop-0_20_2-maintain columnlevel1.fo pagelevel1.fo pagelevel2.fo pagelevel3.fo pagelevel4.fo docs/examples/markers Tag: fop-0_20_2-maintain glossary.xml glossary.xsl hide.fo docs/examples/pagination Tag: fop-0_20_2-maintain allregions.fo basic1.fo basic2.fo franklin_2pageseqs.fo franklin_alt.fo franklin_rep.fo franklin_rep_max_repeats.fo franklin_rep_max_repeats_expl.fo franklin_rep_max_repeats_nl.fo docs/examples/region_body Tag: fop-0_20_2-maintain simplecol.fo simplecol2.fo simplecol3.fo simplecol4.fo docs/examples/svg Tag: fop-0_20_2-maintain boxes.svg embedding.fo external.fo multi.svg ref.svg view.svg docs/examples/tables Tag: fop-0_20_2-maintain background.fo borders.fo break.fo headfoot.fo keep.fo omit.fo space.fo widowsorphans.fo Log: Moved over to examples/fo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/graphics fop.jpg linux.bmp listgeometry.gif page.gif xml_fax.tif xml_feather.gif xml_feather_transparent.gif
jeremias2003/01/13 10:31:33 Removed: docs/graphics Tag: fop-0_20_2-maintain fop.jpg linux.bmp listgeometry.gif page.gif xml_fax.tif xml_feather.gif xml_feather_transparent.gif Log: Moved over to examples/fo/graphics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding documentation
Jeremias Maerki wrote: Yes, but on a new Wiki page on the new API. We've got to scratch together what already has been discussed and put that on that page. I made a page behind the Avalonization link, currently focussing on API issues. Someone with more Avalon background should add internal Avalonization possiblities and perhaps how to deal with configurations. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs/xslfoRef.xml
Jeremias Maerki wrote: There's a xslfoRef.xml containing a small reference for XSL-FO. An XSLT exists for converting the reference to FO. It still reflects the Candidate Recommendation, so it is outdated. Can I simply delete it or should I move it somewhere, too? Keep it for the moment. I think I'll xdocify and update it once I get a bit of time to spare. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
On Monday 13 January 2003 11:01, Oleg Tkachenko wrote: Bernd Brandstetter wrote: feeling inspired by your's and Oleg's suggestions and also a little bit bored this Sunday afternoon, I thought I'll take the chance and improve my Gimping skills. Here's the result :-) Not bad. Something like this I meant. But (sorry for being critical, it's art, not coding :): why it's sitting back to us. No problem :-) This was in no way meant to be a serious proposal for the logo. I've also created one with a parrot sitting with it's front to us. However, I found this one with it's impish look back over the shoulder much nicer. F and P are too simple. Maybe. But IMHO the letters FOP should be easily readable and the whole logo shouldn't be too overloaded with additional stuff. And I'm not sure about scalability - e.g. how it'll look 3cmX2cm? A vector graphic (preferrably SVG) would of course be better. However, I couldn't find a good-looking vectorized parrot clipart. Regards, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
On Monday 13 January 2003 11:05, Jeremias Maerki wrote: On 12.01.2003 11:40:57 Bernd Brandstetter wrote: After having tried to understand how fop works by just reading the code for a couple of hours now, FOrtress inevitably comes to my mind ;-) (in the sense of: Not easy to get in, at least for a newbie) :-) Unfortunately, Fortress is already taken by the Apache Avalon project for one their new containers. I bet they wouldn't be happy to hear your association with the name. Let's be serious again: What do you think could be improved to make FOP easier to get in? Design documentation :-) When I clicked on the Architecture and Design links, I had expected a bit more than 20 to 30 lines of text. But I must admit that I have totally overlooked the Understanding the design section which is a bit more verbose. Still, it would be nice to have something in the style of the Alt design description - which I think is really great - for the standard design too. Regards, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs/xslfoRef.xml
Cool, thanks. On 13.01.2003 19:57:46 J.Pietschmann wrote: Jeremias Maerki wrote: There's a xslfoRef.xml containing a small reference for XSL-FO. An XSLT exists for converting the reference to FO. It still reflects the Candidate Recommendation, so it is outdated. Can I simply delete it or should I move it somewhere, too? Keep it for the moment. I think I'll xdocify and update it once I get a bit of time to spare. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Embedding documentation
Very good. I'll start adding to it as soon as I've finished moving files around and documenting the embedding samples. On 13.01.2003 19:55:22 J.Pietschmann wrote: Jeremias Maerki wrote: Yes, but on a new Wiki page on the new API. We've got to scratch together what already has been discussed and put that on that page. I made a page behind the Avalonization link, currently focussing on API issues. Someone with more Avalon background should add internal Avalonization possiblities and perhaps how to deal with configurations. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
bidi wiki
Oleg: I just added a comment on your bidi wiki, in the Reordering the text section, regarding the line-by-line nature of reordering Middle-Eastern language text. This is something you no doubt already know, but was not clear to me until recently, and it may be helpful. The comments might be expanded to a more general statement by someone who knows more. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Overconstraint wiki
Gang, I just added some newish comments to the overconstraint wiki page. Not much, but it's something. I know some people out there said they had some things to add...please do. I'm hoping to get this ball rolling so that development can get underway as Keiron's work on layout continues. -- J. Rhett Aultman Business Technology Solutions FCCI Insurance Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
On 13.01.2003 19:18:18 Victor Mote wrote:
Jeremias Maerki wrote:
Can we sketch that on the Wiki in some simple way? Defining some Java
interfaces and things like that? Anyway, as you mentioned we should sort
out things like Session and Document on another page first.
OK, I just put a proposal out there in the section discussing Facade. More
on this below.
Mh, yes, I'm not so happy about it, yet. I'll add my comments as
soon as my current task is done.
It would be great if you would read up on Avalon a bit.
I assume that we are talking about the Framework stuff here. I still haven't
found the ServiceManager that you mentioned.
Yes, we're talking about Framework. Framework defines the contracts in
an Avalon system which includes ServiceManager. ServiceManager is the
successor to the ComponentManager which was deprecated because every
service/component had to implement a Component marker interface with no
methods. The ServiceManager now returns simple Objects that need to be
casted to their work interface.
Here's the link to the API docs of the Service package.
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/service/package-summary.html
See here for the Developing with Avalon guide:
http://jakarta.apache.org/avalon/developing/framework.html
(this is a MUST read)
Do I get you right that you would get something like that?
public interface Font {
String getFontName();
int getFontWeight();
int getFontSize();
FontMetrics getFontMetricsForLayout();
}
public interface FontMetrics {
//These methods already take font size into account
int getAscender();
int getDescender();
int getCapHeight();
//more...
int getWidth(char c);
boolean hasKerningAvailable();
//more...
}
That looks promising.
See the wiki where I have added a couple of things to your outline above.
The main difference is that I am not thinking of it as an interface, because
I only ever want one implementation. The concrete class is itself the
interface that the remainder of the system uses. My un-OOP (but not
anti-OOP) background is probably showing through here, so please talk me out
of this if I am out of line.
I guess I will. :-)
The reason for my approach is that ideally,
what we might want here is for java.awt.Font to be in implementation of the
interface that we wish to use. That is not an option. So what we are
building is a /virtual/ interface that we can hide java.awt.Font and /all/
other font concepts behind. We are trying to find commonality between
objects that have similar real-world characteristics, but that have no
compiler-level common heritage. There may be a better way.
There, you are on the right track IMO.
Yes, I share your unease, but I look at it from this side: Multiple area
trees mean possibly different layout which can be a problem when you're
working in an environment where you're working with legally relevant
documents. Two generated documents from the same source must be as equal
as possible. (funny use of equal, I know)
I guess what I am saying is that different fonts used will probably /force/
different area trees. So, from out standpoint, better to disallow it than to
disappoint.
I guess Peter is right that we have to keep it simple for now. Let's
stay on the safe side and be ready to adapt to future changes.
Sorry to be so slow in responding.
No problem. There's so much to do that I'm not getting stuck.
Sorry for not immediately answering in more detail. I've got to get my
head clear for that first.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
On 11.01.2003 18:35:37 Victor Mote wrote:
Keiron Liddle wrote:
If I understand it correctly we could have:
- multiple output targets for one rendering run
- targets with the same font metrics can layout to a common area tree
- targets with similar or substitute metrics could force layout
to one area tree
- other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
The performance gain is not having to do the layout for each output
document which is the major part of a processing run.
The system I wrote for my former employer which is a solution for
high-volume digital printing had to provide a minimal number of pages
per minute. That's usually about 1 to 2 times the speed of the target
printer. So if you have a Xerox DocuTech with 180 pages per minute
and you have to fill an archive with a different format than the one
sent to the printer you'll be happy for such a feature. Especially, if
legal requirements dictate that you need to be able to reprint the
document from the archive and get the same document almost to the pixel.
I'd say we need to be able to do this sometime in the future but not
necessarily now. So let's just make sure this requirement doesn't get
lost and that it stays in the back of our minds when we design the new
thing.
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
That's bad, yes.
Or you could only allow one RenderingContext which results in a
restriction of the available fonts based on the output handlers. You'd
get an error message as soon as an unsupported font is used. When a
common set isn't possible you have to do two rendering runs anyway so we
might just as well delegate this to the caller/user.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
Won't be necessary with my alternative apporach above. But if the user
has to run the layout twice it might be good if the FO tree wasn't lost
between runs.
4. If we build the FO tree up front let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
I think my approach could work in this regard. I'm not sure. We can let
the FO tree live for another layout run, can't we?
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16017] - Jpeg's and the PDF Serializer
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=16017. 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=16017 Jpeg's and the PDF Serializer --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 20:35 --- for a further note. I tested the .PDF file on Adobe Acrobat Reader 5.1 and on xPDF-1.01 on a KDE 3.0.3 running on a RH 8.0 dist. THe pdf viewed in the xPDF looks fine... So maybe some problem with the Adobe showing the pictures. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
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=15985. 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=15985 Hyphenation pattern files appear to be invalid --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 20:49 --- Created an attachment (id=4408) XSL-FO document used to reproduce the exception - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
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=15985. 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=15985 Hyphenation pattern files appear to be invalid --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 20:49 --- Created an attachment (id=4409) Output produced by FOP when processing the XSL-FO input file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/apps AWTStarter.java CommandLineOptions.java CommandLineStarter.java Driver.java ErrorHandler.java FOInputHandler.java FOPException.java Fop.java InputHandler.java LayoutHandler.java
pietsch 2003/01/13 13:05:13
Modified:src/org/apache/fop/apps AWTStarter.java
CommandLineOptions.java CommandLineStarter.java
Driver.java ErrorHandler.java FOInputHandler.java
FOPException.java Fop.java InputHandler.java
LayoutHandler.java
Log:
Fixed more style problems.
Revision ChangesPath
1.17 +15 -7 xml-fop/src/org/apache/fop/apps/AWTStarter.java
Index: AWTStarter.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/AWTStarter.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- AWTStarter.java 6 Nov 2002 14:30:15 - 1.16
+++ AWTStarter.java 13 Jan 2003 21:05:12 - 1.17
@@ -1,6 +1,6 @@
/*
* $Id$
- * Copyright (C) 2001-2002 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 2001-2003 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
@@ -13,8 +13,8 @@
import org.apache.fop.viewer.Translator;
//Java
-import javax.swing.UIManager;
-import java.awt.*;
+import java.awt.Dimension;
+import java.awt.Toolkit;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.util.Locale;
@@ -36,7 +36,13 @@
private Driver driver;
private XMLReader parser;
-public AWTStarter(CommandLineOptions commandLineOptions) throws FOPException {
+/**
+ * Construct an AWTStarter
+ * @param commandLineOptions the parsed command line options
+ * @throws FOPException if anything goes wrong during initialization.
+ */
+public AWTStarter(CommandLineOptions commandLineOptions)
+throws FOPException {
super(commandLineOptions);
init();
}
@@ -44,10 +50,11 @@
private void init() throws FOPException {
//Creates Translator according to the language
String language = commandLineOptions.getLanguage();
-if (language == null)
+if (language == null) {
translator = new Translator(Locale.getDefault());
-else
+} else {
translator = new Translator(new Locale(language, ));
+}
AWTRenderer renderer = new AWTRenderer(translator);
frame = createPreviewDialog(renderer, translator);
renderer.setComponent(frame);
@@ -61,6 +68,7 @@
/**
* Runs formatting.
+ * @throws FOPException FIXME should not happen.
*/
public void run() throws FOPException {
driver.reset();
1.21 +82 -96xml-fop/src/org/apache/fop/apps/CommandLineOptions.java
Index: CommandLineOptions.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- CommandLineOptions.java 31 Oct 2002 17:26:04 - 1.20
+++ CommandLineOptions.java 13 Jan 2003 21:05:12 - 1.21
@@ -1,6 +1,6 @@
/*
* $Id$
- * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 2001-2003 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
@@ -8,19 +8,13 @@
package org.apache.fop.apps;
// java
-import java.util.Vector;
import java.io.File;
import java.io.FileNotFoundException;
-// FOP
-import org.apache.fop.apps.FOPException;
-
// Avalon
import org.apache.avalon.framework.logger.ConsoleLogger;
import org.apache.avalon.framework.logger.Logger;
-import java.io.*;
-
/**
* Options parses the commandline arguments
*/
@@ -54,32 +48,38 @@
private static final int RTF_OUTPUT = 10;
/* show configuration information */
-Boolean dumpConfiguration = Boolean.FALSE;
+private Boolean dumpConfiguration = Boolean.FALSE;
/* suppress any progress information */
-Boolean quiet = Boolean.FALSE;
+private Boolean quiet = Boolean.FALSE;
/* for area tree XML output, only down to block area level */
-Boolean suppressLowLevelAreas = Boolean.FALSE;
+private Boolean suppressLowLevelAreas = Boolean.FALSE;
/* user configuration file */
-File userConfigFile = null;
+private File userConfigFile = null;
/* input fo file */
-File fofile = null;
+private File fofile = null;
/* xsltfile (xslt transformation as input) */
-File xsltfile = null;
+private File xsltfile = null;
/* xml file (xslt transformation as input) */
-File
Re: [PATCH] doc validation fix
Victor Mote wrote: It must be a cultural thing. The dictionary definition you gave should tell the story well enough -- see the example felt contempt for the mincing The word is a pejorative, but perhaps more so in my part of the world, where calling someone a fop or a dandy might be fighting words. In my mind it connotes sissy on one end of the scale and big hat, no cattle on the other. This is all partially mitigated by the fact that the word is pretty much in disuse, so maybe nobody else knows what it means. Finding myself in the minority, I withdraw the question. I intended no offence. As a workaround, please don't be offended if I continue to treat the name as an acronym instead of a word. Victor, Re my comment on this, I thought I should warn you that I am addicted to ironical jokes, which can be a dangerous habit with email. I dislike emoticons, probably because I am more of a snob than I like to admit, but also because they seem to me to discourage any attempt either to write or to read the subtle - or the ironical! - from email. An advantage of the longevity of a forum like this is that we get to know each other's style, so I hope that my un-emoticoned attempts at humour are read as such. I'll see if I can squeeze one out. ,; :) ;, 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]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
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=15985. 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=15985 Hyphenation pattern files appear to be invalid --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 21:20 --- I've checked my classpath by manually inspecting the java lib directories and the jar files passed to FOP (see below) and don't believe that a duplicate exists in my classpath. I even tried stripping my document down to a bare minimum and still receive a hyphenation exception. I've attached the XSL-FO document which is producing the error. If I run FOP 0.20.4 (by replacing the entire FOP jar), the exception no longer appears, which leads me to believe that this might indeed be a problem with 0.20.5rc. Could you please attempt to generate a PDF from the attached FO file to see if you can reproduce the error? Thanks, Shawn This is the command that I've been using to run FOP: /cygdrive/c/jdk1.3.0_02/bin/java -Xms512m -Xmx1028m -classpath C:\Oracle\Ora81\orb\classes\yoj.jar; C:\Oracle\Ora81\orb\classes\share.zip; c:\modeln_education\tools\docbook\lib\ant-1.4.1.jar; c:\modeln_education\tools\docbook\lib\avalon-framework-cvs-20020315.jar; c:\modeln_education\tools\docbook\lib\batik.jar; c:\modeln_education\tools\docbook\lib\bsf.jar; c:\modeln_education\tools\docbook\lib\buildtools.jar; c:\modeln_education\tools\docbook\lib\fop-0.20.5rc.jar; c:\modeln_education\tools\docbook\lib\jfor-0.7.1.jar; c:\modeln_education\tools\docbook\lib\jimi-1.0.jar; c:\modeln_education\tools\docbook\lib\stylebook.jar; c:\modeln_education\tools\docbook\lib\xercesImpl-2.2.1.jar; c:\modeln_education\tools\docbook\lib\xml-apis.jar; c:\modeln_education\tools\docbook\lib\xalan\xalan-2.4.1.jar; c:\modeln_education\tools\docbook\lib\xalan\xalan-2.x.x-xsl.jar org.apache.fop.apps.Fop -fo content/devguide/book_xml.fo -pdf xml_content.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
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=15985. 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=15985 Hyphenation pattern files appear to be invalid --- Additional Comments From [EMAIL PROTECTED] 2003-01-13 21:22 --- Oh yes, and I did try a complete rebuild of FOP 0.20.5rc with the same results. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
Bernd Brandstetter wrote: On Monday 13 January 2003 11:01, Oleg Tkachenko wrote: Bernd Brandstetter wrote: feeling inspired by your's and Oleg's suggestions and also a little bit bored this Sunday afternoon, I thought I'll take the chance and improve my Gimping skills. Here's the result :-) Not bad. Something like this I meant. But (sorry for being critical, it's art, not coding :): why it's sitting back to us. No problem :-) This was in no way meant to be a serious proposal for the logo. I've also created one with a parrot sitting with it's front to us. However, I found this one with it's impish look back over the shoulder much nicer. I agree. It's more interesting that way. F and P are too simple. Maybe. But IMHO the letters FOP should be easily readable and the whole logo shouldn't be too overloaded with additional stuff. Yes, but that still leaves quite a bit of room for font experimentation. 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]
Re: FOP logo
At 04:34 PM 1/13/03, you wrote: Maybe. But IMHO the letters FOP should be easily readable and the whole logo shouldn't be too overloaded with additional stuff. Yes, but that still leaves quite a bit of room for font experimentation. I cannot resist - How many programmers does it take to change a logo ?|;^) ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Rotating Text Elements
Hello all, I have looked over the list and have found references to the fact that the reference-orientation element is not currently implemented, and the suggestion that rotating text can be accomplished by embedding svg. However, a cursory examination of svg seems to indicate that there is no support for external fonts (as is currently supported in FOP). So, if I wanted to include a sidebar on a regular PDF document (8.5 x 11 text running left to right), containing a non-standard font, with the text running top to bottom, it looks like I'm out of luck... My questions: 1.To the best of your knowledge (as I know this is not the SVG list) - Does SVG support external fonts? 2.If reference-orientation were supported, would I be able to accomplish my task? 3.Will reference-orientation be supported in a future release? and, if so, when? 4.And, finally, any other suggestions for accomplishing this using FOP? My thanks, Angus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
Ralph LaChance wrote: At 04:34 PM 1/13/03, you wrote: Maybe. But IMHO the letters FOP should be easily readable and the whole logo shouldn't be too overloaded with additional stuff. Yes, but that still leaves quite a bit of room for font experimentation. I cannot resist - How many programmers does it take to change a logo ?|;^) NaN In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) You've found the attribution. One of my favourites. 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]
Re: Rotating Text Elements
Angus Stewart wrote: 1.To the best of your knowledge (as I know this is not the SVG list) - Does SVG support external fonts? You'll have to install your font with the AWT. I have no idea how easy or complicated this is. If you are running Unix+X it is probably enough to register the font with X. On Windows, it may be enough to drop the file into the font directory. 3.Will reference-orientation be supported in a future release? Yes. and, if so, when? Perhaps summer, but don't hold your breath. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] doc validation fix
Peter B. West wrote: Re my comment on this, I thought I should warn you that I am addicted to ironical jokes, which can be a dangerous habit with email. I dislike emoticons, probably because I am more of a snob than I like to admit, but also because they seem to me to discourage any attempt either to write or to read the subtle - or the ironical! - from email. An advantage of the longevity of a forum like this is that we get to know each other's style, so I hope that my un-emoticoned attempts at humour are read as such. I'll see if I can squeeze one out. ,; :) ;, We're OK. I caught your irony. My response was really entirely to Oleg's question. However, I really was concerned about offending someone -- things like names and logos carry a certain emotional weight. In other words, I might worry about offending some on this list, but it really wouldn't bother me to offend you at all, Peter. VVBG :-) Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
Victor Mote wrote: We're OK. I caught your irony. My response was really entirely to Oleg's question. However, I really was concerned about offending someone -- things like names and logos carry a certain emotional weight. In other words, I might worry about offending some on this list, but it really wouldn't bother me to offend you at all, Peter. VVBG :-) Touche'. 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]
DO NOT REPLY [Bug 15936] - Leading causes space deletion/word misplacement
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=15936. 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=15936 Leading causes space deletion/word misplacement --- Additional Comments From [EMAIL PROTECTED] 2003-01-14 01:20 --- Created an attachment (id=4413) DocBook-generated FO file demonstrating narrowed spacing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15936] - Leading causes space deletion/word misplacement
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=15936. 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=15936 Leading causes space deletion/word misplacement --- Additional Comments From [EMAIL PROTECTED] 2003-01-14 01:37 --- I see now that the spacing is not completely gone. However, it appears that it has been crunched down to the absolute minimum value. In 20.5, the inter-word spaces in the TOC are smaller than the inter-word spacing in the regular text of the document. This was not the case of 20.4. My guess is that the leader is (now) pushing the spacing to its minimum value. Admittedly, this is not the most important bug in the world, but the quality of the documents' appearance did decrease slightly between 20.4 and 20.5. Thanks for your work on this tool. It is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16047] New: - PDF bookmark extension example is missing closing tag
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=16047. 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=16047 PDF bookmark extension example is missing closing tag Summary: PDF bookmark extension example is missing closing tag Product: Fop Version: 0.20.5 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] At the URL http://xml.apache.org/fop/extensions.html, there is an example showing how to use the PDF bookmark extension. Line #9 should be a closing tag instead of an opening tag. Below is the example copied from the extensions page: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:fox=http://xml.apache.org/fop/extensions; fox:outline internal-destination=sec3 fox:labelRunning FOP/fox:label fox:outline internal-destination=sec3-1 fox:labelPrerequisites/fox:label /fox:outline fox:outline== This should be a closing tag /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Rotating Text Elements
On 13.01.2003 23:24:49 J.Pietschmann wrote: Angus Stewart wrote: 1.To the best of your knowledge (as I know this is not the SVG list) - Does SVG support external fonts? You'll have to install your font with the AWT. I have no idea how easy or complicated this is. If you are running Unix+X it is probably enough to register the font with X. On Windows, it may be enough to drop the file into the font directory. You could also try to set the strokeSVGText property to false. This will delegate text painting to FOP (instead of Batik) which can use its own fonts. Though with rotated text I've had my problems. The redesigned FOP will do this a lot better in the future. http://xml.apache.org/fop/svg.html Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15936] - Leading causes space deletion/word misplacement
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=15936. 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=15936 Leading causes space deletion/word misplacement --- Additional Comments From [EMAIL PROTECTED] 2003-01-14 07:02 --- Both space width calculation and the space justification (LineArea.align()) have changed. I'd suspect the latter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Victor Mote wrote: Jeremias Maerki wrote: It is very possible that I am missing something, but our memory-lean event-based model would seem to dictate either 1) parsing the document twice, or 2) not allowing multiple output formats in the same document. I think my approach could work in this regard. I'm not sure. We can let the FO tree live for another layout run, can't we? I have no objection to it. However, AFAIK our processor doesn't really process an FO tree, it processes events that occur as the FO tree is built. So, you need to add something that walks through the existing FO tree starts creating events to feed into our processor. I don't know how much faster this might be than just reprocessing the original input. Then you need something in the process that says Oh, don't try to build an FO tree here, it already exists. In other words, we're kind of trying to reuse something that we didn't use the first time -- it all seems kind of klunky. It seems to me that if we want to go down that path, we would do well to build an FO tree up front, caching it for those who need a lean memory environment, then process that tree n times, all the same way. I am not really arguing for that, but merely pointing out that it seems like that is where reusing the FO tree leads us. There's one in alt.design if you ever need it. 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]
