cvs commit: xml-fop/src/documentation/content/xdocs anttask.xml bugs.xml compiling.xml compliance.xml configuration.xml download.xml embedding.xml examples.xml extensions.xml faq.xml fo.xml fonts.xml gethelp.xml graphics.xml hyphenation.xml index.xml license.xml logocontest.xml maillist.xml news.xml output.xml pdfencryption.xml relnotes.xml resources.xml running.xml servlets.xml status.xml tabs.xml team.xml

vmote 2003/11/12 07:12:00 Modified:src/documentation/content/xdocs anttask.xml bugs.xml compiling.xml compliance.xml configuration.xml download.xml embedding.xml examples.xml extensions.xml faq.xml fo.xml fonts.xml

cvs commit: xml-fop/src/documentation/content/xdocs/dev api-doc.xml conventions.xml doc.xml extensions.xml faq.xml fonts.xml implement.xml index.xml release.xml rtflib.xml svg.xml testing.xml tools.xml

vmote 2003/11/12 07:24:53 Modified:src/documentation/content/xdocs/design areas.xml breakpos.xml embedding.xml extending.xml fotree.xml images.xml index.xml layout.xml optimise.xml parsing.xml pdf-library.xml prope

cvs commit: xml-fop/src/documentation/content/xdocs resources.xml

vmote 2003/11/12 07:29:59 Modified:src/documentation/content/xdocs resources.xml Log: add link for UTR-14 Revision ChangesPath 1.32 +7 -1 xml-fop/src/documentation/content/xdocs/resources.xml Index: resources.xml

RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TextLayoutManager.java

J.Pietschmann wrote: > [EMAIL PROTECTED] wrote: > > Hyphenation problem in Bug 23985 > > Actually, implementing UTR14 would solve the line breaking problem, > although not the URL breaking problem. > > Points to discuss: ... > - Should we provide for custom line breaking algorithms? > Some l

CVS (src & bin) zip'd up for nightlies?

Is it possible we could implement a system to get the CVS nightlies (src &/or bin) for fop-1.0Dev zipped and/or tar'd for simple downloading and available from the Dev tab? Having to log in with CVS access is kind of a pain, and I don't know of another way to download the stuff. It might also

FOP logo update

I was unable to make much progress on this topic. I am unable to get SVG and/or vector versions of the logo. We do, however, have a JPG version. -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - PGP Public Key:

Whole Web Site PDF update

FWIW, I'm still planning on making updates on this front. However, it's taken more time than I planned getting familiar with Forrest. -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - PGP Public Key:

cvs commit: xml-fop/src/documentation/content/xdocs faq.xml fo.xml

vmote 2003/11/12 09:28:07 Modified:src/documentation/content/xdocs faq.xml fo.xml Log: add doc for using current date and time, and create an FAQ referencing it Revision ChangesPath 1.40 +6 -0 xml-fop/src/documentation/content/xdocs/faq.xml Index: faq.xml

cvs commit: xml-fop/src/documentation/content/xdocs fo.xml

vmote 2003/11/12 09:41:06 Modified:src/documentation/content/xdocs fo.xml Log: make external site a jump instead of link Revision ChangesPath 1.10 +2 -2 xml-fop/src/documentation/content/xdocs/fo.xml Index: fo.xml ===

RE: FOP logo update

Clay Leeds wrote: > I was unable to make much progress on this topic. I am unable to get > SVG and/or vector versions of the logo. We do, however, have a JPG > version. Thanks for your efforts here. I'll work on creating an svg version. Victor Mote

RE: Setup code in Driver

Jeremias Maerki wrote: > I'm not in a fighter mood today so please change getContentHandler() > to something other than public, make sure you check the test cases > regularly, adjust the example code to the new API and keep in mind that > Cocooners will want to migrate their FOPSerializer some day

DO NOT REPLY [Bug 24658] New: - fo:external-graphic does not support SVG when src is an url

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: CVS (src & bin) zip'd up for nightlies?

> -Original Message- > From: Clay Leeds [mailto:[EMAIL PROTECTED] > > Is it possible we could implement a system to get the CVS nightlies > (src &/or bin) for fop-1.0Dev zipped and/or tar'd for simple > downloading and available from the Dev tab? Having to log in with CVS > access is kind o

DO NOT REPLY [Bug 24663] New: - fo:block space-after property needs fixing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: CVS (src & bin) zip'd up for nightlies?

On Wednesday, November 12, 2003, at 12:51 PM, Andreas L. Delmelle wrote: -Original Message- From: Clay Leeds [mailto:[EMAIL PROTECTED] Is it possible we could implement a system to get the CVS nightlies (src &/or bin) for fop-1.0Dev zipped and/or tar'd for simple downloading and available

RT: line breaking

Victor Mote wrote: I know of at least two line-breaking strategies that we probably want to have in our stock strategies: 1) the line-by-line method used right now, and 2) a Tex-like paragraph-oriented strategy, which AFAIK doesn't exist yet. Ahem, that's not what I meant, or the scope of UTR14. UT

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TextLayoutManager.java

Glen Mazza wrote: Make sure you're separating the issues here... Uh, sorry the issue hasn't really much to do with your patch except that it is in roughly the same region of code... I should have started a new thread. Probably more than just Western, here's a Japanese description: http://java.sun

Re: CVS (src & bin) zip'd up for nightlies?

Clay Leeds wrote: BTW, IIRC it's been discussed on the list (ad nauseam) that the official "tag" name is HEAD, but frankly, I don't remember why so many terms appear to be synonymous. Yes, standardizing language in the docs makes sense. However re-tag it in CVS? I don't think this is appropriate

DO NOT REPLY [Bug 24666] New: - fo:instream-foreign-object: SVG w/6-digit translates not rendering well

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: RT: line breaking

J.Pietschmann wrote: Be careful with the various TRs: UTR14 does not deal with character (rather: grapheme) or word boundaries, that's UTX-29. Actually, we don't use the latter. Our line breaking should probably be done the following way (this implements the "naive" paragraph filling strategy) lo