Re: Lest we forget (please use REPLY!)
On Friday 26 April 2002 08:09, Bertrand Delacretaz wrote: This probably helps: http://www.anzacday.org.au/ sorry for the noise - I didn't see that the question had long been answered. PLEASE everybody use reply-to when replying to mailing lists messages. With the right mail client, it allows discussions threads to stay together. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: background-image patch v0.03 in CVS
Sorry - forgot to attach Enrico Am Donnerstag, 25. April 2002 21:41 schrieben Sie: Hello Mike, image problem ... I am generating fo files from html. In html (as in fop web site the blue headings) images are often very small. Exist there a fo property which might not be implemented yet but is responsible for handling this behavior. Good question. I've encountered this before, but given I can't remember what caused it or what I did to make it go away, so it can't be too important.. 8) If you can send me a minimal test case, or (preferably) open a bug on this issue, assugn it to me and attach the test case to that, I'll take a look at it. I've attached the minimal test case. It can't be a smaller .fo file - only a table with nothing in it and a block - that's all. Thanks Enrico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=first fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=first fo:flow flow-name=xsl-region-body fo:table table-layout=fixed fo:table-column column-width=5cm / fo:table-body fo:table-row fo:table-cell /fo:table-cell /fo:table-row /fo:table-body /fo:table fo:blockIf the table or this paragraph is leaved out fop works ok./fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/pdf/fonts LazyFont.java
keiron 02/04/26 01:51:01
Modified:src/org/apache/fop/render/pdf/fonts LazyFont.java
Log:
comment for possible thread problem
Revision ChangesPath
1.6 +4 -1 xml-fop/src/org/apache/fop/render/pdf/fonts/LazyFont.java
Index: LazyFont.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/fonts/LazyFont.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- LazyFont.java 11 Feb 2002 09:45:39 - 1.5
+++ LazyFont.java 26 Apr 2002 08:51:01 - 1.6
@@ -1,5 +1,5 @@
/*
- * $Id: LazyFont.java,v 1.5 2002/02/11 09:45:39 keiron Exp $
+ * $Id: LazyFont.java,v 1.6 2002/04/26 08:51:01 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -34,6 +34,9 @@
if(! isMetricsLoaded){
isMetricsLoaded = true;
try{
+
+// TODO - Possible thread problem here
+
FontReader reader = new FontReader(metricsFileName);
reader.useKerning(useKerning);
reader.setFontEmbedPath(fontEmbedPath);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PCL renderer limitations
Art Welch wrote:
[EMAIL PROTECTED]">
I am the person who is mostly to blame for the PCLRenderer. Unfortunately
I have not been able to work on it for a while - and I do not know when
I will be able to do so. Of course anyone else is free to work on it - but
I have not seen many others doing much on it.
If there are some particular limitations that you find most onerous, perhaps
I can take a look at them... especially if they are easy to fix. However
the main limitations that I am aware of will require significant effort.
These are restoring SVG support, adding font support, adding color support,
etc.
At present I think that it is unlikely that any significant limitations
in the PCLRenderer will be addressed in the short term. It is quite possible
that this could change. Next week I am planning on trying to get more resources
committed to XML reporting at my employer. If successful, I may be able
to spend more time on FOP.
Well, that's fine ;-)
Hi, I have problems too with the PCL renderer. The PDF renderer works fine
for:
-handling tables aligned right in the footer ("Page N1/5" for exemple
in a one cell table
aligned right).
-handling images centered inside a fo:block.
I just can't do that with the PCL renderer, which doesn't produce the whole
thing in the footer
(stops to "Page N" and then ... nothing more in the footer...). If I ever
use a single fo:block
aligned right, this does work... Si this problem is not really urgent for
me.
But the image centering is quite important, and I still haven't found a new
way of getting it centered.
Can you help?
Thanks a lot!
Bruno Verachten.
[GUMP] Build Failure - xml-fop
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-04-26/xml-fop.html Buildfile: build.xml init-avail: init-filters-xalan2: [copy] Copying 1 file to /home/rubys/jakarta/xml-fop/build/src/codegen init: [echo] --- Fop 1.0dev [1999-2002] prepare: [echo] Preparing the build directories [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/svg [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/conf [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/hyph [copy] Copying 3 files to /home/rubys/jakarta/xml-fop/build/classes/conf codegen: [echo] Resetting codegen directory [copy] Copying 30 files to /home/rubys/jakarta/xml-fop/build/src/codegen [echo] Generating the java files from xml resources [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/allprops.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/Constants.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/genconst.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/fo_ignore_this.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/properties.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/FOPropertyMapping.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/propmap.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/foenums_ignore_this.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/enumgen.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/charlist.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/CodePointMapping.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/code-point-mapping.xsl [style] Transforming into /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierBold.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierBold.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Courier.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Courier.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierBoldOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierBoldOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Helvetica.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Helvetica.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/HelveticaBold.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/HelveticaBold.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/HelveticaBoldOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/HelveticaBoldOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/HelveticaOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/HelveticaOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Symbol.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Symbol.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesBold.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesBold.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesBoldItalic.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesBoldItalic.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesItalic.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesItalic.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesRoman.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesRoman.java [style] Processing
Fop in UNIX or Linux
Hi, all I have generated a file XML with descritpions by the fonts specials (barcode, arial, etc.), but I have put into S.O. UNIX or Linux. In a the file xml, I have declarated into a file the next sentences. font metrics-file=./webapps/site/fop/xml/i2of5NT.xml kerning=yes embed-file=c:\winnt\fonts\I2OF5NT.ttf font-triplet name=Interleaved2of5NT style=normal weight=normal / /font But, I have the problem with embed-file=c:\winnt\fonts\I2OF5NT.ttf, I don't understand with the sentences embed-file when I used in S.O. Unix. Where I put this file (.ttf) into Unix or Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
line layout commit
Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. The main things that need thinking about are: - range properties - wrapping (ie. no wrap) - whitespace and linefeed handling - Unicode BIDI (this looks hard) It is very rough at the moment, the idea is to get a basis so that inline areas can be created and put into line areas and this will fit into the overall design. This leaves us with a simpler way of handing inline areas. So whats next? It is possible to start looking at fully implementing inline areas, eg. image, instream-foreign-object, leader, character. Getting pagination working will be a big step forward. Then we need to block area layout managers, like tables and lists. So what do people think? Regards, Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
external-graphic size
Hi all I've a problem with external graphics, which can be greater than the page size of the xsl-template. The properties max-height and max-width doesn't work (not implemented). The result is an infinite loop on rendering the (correctly) generated fo-file with the AWTRenderer to display the result. Is there a workaround for that or have I omit an important setting (possible in xsl) for a parent object. cu Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Open source rtf2fo
Does anyone of you guys know an open source project running on a conversion from rtf to xsl:fo? Thanks Berni - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Understanding] Layout Managers [10.0]
Layout Managers --- The role of the layout managers is to build the Area Tree by using the information from the FO Tree. The layout managers decide where information is placed in the area tree. A layout manager is typically associated with an FO Object but not always. The layout managers are in between the FO Tree and the Area Tree. They get information from the FO Tree and create areas and build the pages. They hold the state of the layout process as it builds up the areas and pages. They also manage the handling of breaks and spacing between areas. FO Objects can have two types of properties, ones that relate to the layout and ones that relate to the rendering. THe layout related properties area used by the layout managers to determine how and where to create the areas. The render related properties should be passed through to the renderer in the most efficient way possible. Block Areas --- When a block creating element is complete then it is possible to build the block area and add it to the paprent. A block area will contain either more block areas or line areas, which are special block areas. The line areas are created by the LineLayoutManager in which the inline areas flow into. So a block area manager handles the lines or blocks as its children and determines things like spacing and breaks. In the case of tables and lists the blocks are stacked in a specific way that needs to be handled by the layout manager. Side Floats --- Side floats alter the length of the inline progression dimension for the current line and following lines for the size of the float. This means that the float needs to be handled by the block layout manager so that it can adjust the available inline progression dimension for the relevant line areas. Footnotes Before Floats - Footnotes and Before Floats are placed in special areas in the body region of the page. The size of these areas is determined by the content. This in turn effects the available size of the main reference area that contains the flow. A layout manager handles the adding and removing of footnotes/floats, this in turn effects the available space in the main reference area. (note: more info to follow) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Lest we forget
From: Bertrand Delacretaz [EMAIL PROTECTED] This probably helps: http://www.anzacday.org.au/ -Bertrand In Italy we had Liberation Day. 25AprilAnniversary of the Revolution in Portugal 25AprilAnzac Day in Australia 25AprilAnzac Day in Cook Islands 25AprilAnzac Day in New Zealand 25AprilAnzac Day in Tonga 25AprilAnzac Day in Western Samoa 25AprilLiberation Day in Italy 25AprilLiberation Day in Portugal 25AprilNational Flag Day in Swaziland 25AprilSinai Liberation Day in Egypt Funny how Gallipoli is also an Italian town. This is a small world indeed... On Friday 26 April 2002 00:38, Martin Stricker wrote: Peter B. West wrote: Age shall not weary them, nor the years contemn. At the going down of the sun, and in the morning, We shall remember them. Lest we forget. Anzac Day 25th April 2002 Could you please explain this e-mail? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PFM file?
Hi all I need know what it this? I work in S.O. Unix, but I don't know it this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Understanding] Layout Managers [10.0]
Keiron, Here is the Layout Lanagers section win the xml corresponding format. I have added the book.xml as well with a little change. (tell me if you prefer diff file) These two files are to be put in the ../design/understanding/ directory. ;-) Cyril book.xml Description: application/xml layout_managers.xml Description: application/xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[DOCUMENTATION] Re: [Understanding] Layout Managers [10.0]
oops Sorry for those who receive this twice, I have already sent this message but I have forgotten the DOCUMENTATION Subject header. _ Keiron, Here is the Layout Lanagers section in the corresponding xml format. I have added the book.xml as well with a little change. (tell me if you prefer diff file) These two files are to be put in the ../design/understanding/ directory. ;-) Cyril book.xml Description: application/xml layout_managers.xml Description: application/xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PCL renderer limitations
Hmmm.
These are interesting.
On the
table problem, could it be that the part that appears to not be printing is
actually outside of the printer's printable area?
How
much is the image off center? If it just appears to be a little off center it
may be because the PCLRenderer only supports images scaled in discrete steps.
FOP's layout is unaware of this, so it may be placing the image based on what it
thinks the actual scaled size is - not the size the PCLRenderer will produce.
IIRC images are placed by the upper left corner - so this could cause an image
to appear off center.
HTH,
Art
-Original Message-From: Bruno Verachten
[mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002
5:35 AMTo: [EMAIL PROTECTED]Cc: Art
WelchSubject: Re: PCL renderer limitationsArt
Welch wrote:
[EMAIL PROTECTED]"
type="cite">
I
am the person who is mostly to blame for the PCLRenderer. Unfortunately I
have not been able to work on it for a while - and I do not know when I will
be able to do so. Of course anyone else is free to work on it - but I have
not seen many others doing much on it.
If
there are some particular limitations that you find most onerous, perhaps I
can take a look at them... especially if they are easy to fix. However the
main limitations that I am aware of will require significant effort. These
are restoring SVG support, adding font support, adding color support,
etc.
At
present I think that it is unlikely that any significant limitations in the
PCLRenderer will be addressed in the short term. It is quite possible that
this could change. Next week I am planning on trying to get more resources
committed to XML reporting at my employer. If successful, I may be able to
spend more time on FOP.Well, that's fine
;-)Hi, I have problems too with the PCL renderer. The PDF renderer works
fine for: -handling tables aligned right in the footer
("Page N°1/5" for exemple in a one cell table
aligned right). -handling images centered inside a
fo:block.I just can't do that with the PCL renderer, which doesn't
produce the whole thing in the footer(stops to "Page N°" and then ...
nothing more in the footer...). If I ever use a single fo:block aligned
right, this does work... Si this problem is not really urgent for
me.But the image centering is quite important, and I still haven't
found a new way of getting it centered.Can you help?Thanks a
lot!Bruno Verachten.
PDF to RTF
Does anybody know of a PDF to RTF converter written in Java (preferably)? Or does anybody know of a XSL:FO based RTF renderer? I tried the jfor one but is not sufficient for what I am trying to do...(lacks support for headers, borders footers etc)
Re: PCL renderer limitations
Art Welch wrote: [EMAIL PROTECTED]"> Hmmm. These are interesting. On the table problem, could it be that the part that appears to not be printing is actually outside of the printer's printable area? Maybe... [EMAIL PROTECTED]"> How much is the image off center? Totally ;-) [EMAIL PROTECTED]"> If it just appears to be a little off center it may be because the PCLRenderer only supports images scaled in discrete steps. FOP's layout is unaware of this, so it may be placing the image based on what it thinks the actual scaled size is - not the size the PCLRenderer will produce. IIRC images are placed by the upper left corner - so this could cause an image to appear off center. I'm sorry, but what are IIRC images? Here is the fo code I have: fo:block text-align="center" text-indent="1em" space-before="0.6em" space-after="0.6em" font-size="10pt" display-align="center" fo:external-graphic src="Logo.gif" content-height="53px" content-width="88px" scaling="uniform" scaling-method="auto"/ /fo:block Thanks. Bruno Verachten
RE: PCL renderer limitations
IIRC == "If I recall correctly." The statement would thus read, "If I recall correctly, images are placed by the upper left corner..." -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 1:01 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitationsArt Welch wrote: [EMAIL PROTECTED]" type="cite"> Hmmm. These are interesting. On the table problem, could it be that the part that appears to not be printing is actually outside of the printer's printable area?Maybe... [EMAIL PROTECTED]" type="cite"> How much is the image off center? Totally ;-) [EMAIL PROTECTED]" type="cite"> If it just appears to be a little off center it may be because the PCLRenderer only supports images scaled in discrete steps. FOP's layout is unaware of this, so it may be placing the image based on what it thinks the actual scaled size is - not the size the PCLRenderer will produce. IIRC images are placed by the upper left corner - so this could cause an image to appear off center.I'm sorry, but what are IIRC images? Here is the fo code I have:fo:block text-align="center" text-indent="1em" space-before="0.6em" space-after="0.6em" font-size="10pt" display-align="center"fo:external-graphic src="Logo.gif" content-height="53px" content-width="88px" scaling="uniform" scaling-method="auto"//fo:blockThanks.Bruno Verachten
Czech translation for AWT viewer
Hi Fops, I translate messages and resources for AWT viewer, can you commit it? It's in ISO-8859-2 coding. Thanks Michal AWTczech.zip AWTczech.zip Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PCL renderer limitations
If the image is totally off center, then the problem is probably not related to scaling. "IIRC images", sorry I should have included a comma in there as in: "If I remember correctly, images..." It seems a bit odd to me that the PDF renderer would center the image properly and the PCL renderer would not center it at all. I have not looked at the code in a long time, but I thought that FOP did all the layout before calling the renderer. So it should just be saying "put the image here" and supplying the appropriate coordinates to the renderer. But it is entirely possible that this had changed - or perhaps even more likely - I am not remembering correctly. I have not looked at FOP code much since the redesign started. Art -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 1:01 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitationsArt Welch wrote: [EMAIL PROTECTED]" type="cite"> Hmmm. These are interesting. On the table problem, could it be that the part that appears to not be printing is actually outside of the printer's printable area?Maybe... [EMAIL PROTECTED]" type="cite"> How much is the image off center? Totally ;-) [EMAIL PROTECTED]" type="cite"> If it just appears to be a little off center it may be because the PCLRenderer only supports images scaled in discrete steps. FOP's layout is unaware of this, so it may be placing the image based on what it thinks the actual scaled size is - not the size the PCLRenderer will produce. IIRC images are placed by the upper left corner - so this could cause an image to appear off center.I'm sorry, but what are IIRC images? Here is the fo code I have:fo:block text-align="center" text-indent="1em" space-before="0.6em" space-after="0.6em" font-size="10pt" display-align="center"fo:external-graphic src="Logo.gif" content-height="53px" content-width="88px" scaling="uniform" scaling-method="auto"//fo:blockThanks.Bruno Verachten
RE: PCL renderer limitations
Sorry, I'm American and my grammar is pretty bad. I think that your english is probably still better than mine... -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 1:11 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitationsRhett Aultman wrote: [EMAIL PROTECTED]" type="cite"> IIRC == "If I recall correctly." The statement would thus read, "If I recall correctly, images are placed by the upper left corner..."Oopss... Sorry, I'm french AND my english is pretty bad...Thanks for your necesseray help ;-)Later,Bruno Verachten
RE: PCL renderer limitations
Yeah,
Bruno- you've got nothing to worry about with your English. I didn't even
once assume English wasn't your first language.
Stuff
like IIRC and AFAIK ("as far as I know") are just shorthand ways of writing
common phrases that some of us seem to have picked up from being on usenet too
much.
-Original Message-From: Art Welch
[mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 1:51
PMTo: '[EMAIL PROTECTED]'Subject: RE: PCL renderer
limitations
Sorry,
I'm
American and my grammar is pretty bad.
I
think that your english is probably still better than
mine...
-Original Message-From: Bruno Verachten
[mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002
1:11 PMTo: [EMAIL PROTECTED]Subject: Re: PCL
renderer limitationsRhett Aultman wrote:
[EMAIL PROTECTED]">
IIRC == "If I recall correctly."
The statement would thus read, "If I recall correctly, images
are placed by the upper left
corner..."Oopss... Sorry, I'm french AND my
english is pretty bad...Thanks for your necesseray help
;-)Later,Bruno
Verachten
Re: PCL renderer limitations
[EMAIL PROTECTED]"> If the image is totally off center, then the problem is probably not related to scaling. "IIRC images", sorry I should have included a comma in there as in: "If I remember correctly, images..." It seems a bit odd to me that the PDF renderer would center the image properly and the PCL renderer would not center it at all. I have not looked at the code in a long time, but I thought that FOP did all the layout before calling the renderer. So it should just be saying "put the image here" and supplying the appropriate coordinates to the renderer. But it is entirely possible that this had changed - or perhaps even more likely - I am not remembering correctly. I have not looked at FOP code much since the redesign started. Okay... If you have time on your hands next week, I can send my fo code to the list. I have to leave now (8pm here), so ... have a nice week-end. Thanks for the answers, including the ones about shorthands ;-) Bruno Verachten.
RE: PCL renderer limitations
If the PDFRenderercenters the image properlyand the PCLRenderer does not then it is probably a bug in FOP (likely the PCLRenderer) not a problem with the FO code. Art -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 2:11 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitations [EMAIL PROTECTED]" type="cite"> If the image is totally off center, then the problem is probably not related to scaling. "IIRC images", sorry I should have included a comma in there as in: "If I remember correctly, images..." It seems a bit odd to me that the PDF renderer would center the image properly and the PCL renderer would not center it at all. I have not looked at the code in a long time, but I thought that FOP did all the layout before calling the renderer. So it should just be saying "put the image here" and supplying the appropriate coordinates to the renderer. But it is entirely possible that this had changed - or perhaps even more likely - I am not remembering correctly. I have not looked at FOP code much since the redesign started. Okay... If you have time on your hands next week, I can send my fo code to the list.I have to leave now (8pm here), so ... have a nice week-end.Thanks for the answers, including the ones about shorthands ;-)Bruno Verachten.
RE: line layout commit
Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) As far as the Unicode bidi algorithm is concerned, yup, no kidding. :-) Have you looked at the Java reference implementation for it? :-) Not a trivial thing. Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 26, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: line layout commit Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. The main things that need thinking about are: - range properties - wrapping (ie. no wrap) - whitespace and linefeed handling - Unicode BIDI (this looks hard) It is very rough at the moment, the idea is to get a basis so that inline areas can be created and put into line areas and this will fit into the overall design. This leaves us with a simpler way of handing inline areas. So whats next? It is possible to start looking at fully implementing inline areas, eg. image, instream-foreign-object, leader, character. Getting pagination working will be a big step forward. Then we need to block area layout managers, like tables and lists. So what do people think? Regards, Keiron. - 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: line layout commit
Hi Keiron, On the one hand, I'm happy to see new work in the LayoutManagers. On the other hand, it turns out, I have been plugging (unfortunately really slowly) away at the Break Possibility ideas I mentioned a while back and just this very evening I had gotten the Line and Text LayoutManagers to where they were actually generating areas based on the BreakPoss ... and maybe it was ready for CVS. ... really I'm not kidding. That was when I discovered that you had beat me to it by a few hours. I only saw your thinking aloud mail last night and my feeling was that apart from the flattening of inline LM idea, there might not be such a big difference in our approaches. But of course, the code itself is quite different. I had done a bunch of work in Text and Line LM, but mostly it was totally new code, so after the CVS update your new stuff and mine are more or less coexisting. But I'll have another look at this tomorrow when I'm less tired to understand the details of your new stuff and to see if there's any useful way to integrate mine into it. It looks like you didn't change TextLayoutManager that much, so maybe some of my changes there could be worked in. The big difference is that I'm first generating a bunch of BreakPoss on the inline level which the LineLayoutManager is using to choose a break. In theory, it could do this for several lines at a time, but right now, it's just trying to do one. The the LineLM is also generating BreakPoss which represent the LineAreas it would create. Those eventually get bubbled up to the FlowLayoutManager which does basically the same thing as the LineLM. When it's happy, it uses the BreakPoss objects to have all the lower level LM generate the actual areas. I'll also have to adapt to the switch between getLayoutManager and addLayoutMangers though. I remember you mentioning this a while back, but I had continued to work along the original path. Don't think that will be too hard to do though. What I liked about the original approach is the idea that we could be laying out the tree in one thread and building it in another. But maybe that's still possible, just on a different level of chunking. At any rate, I'll try to see if I can add anything useful to your work. Do you think it's worthwhile trying to integrate the BreakPoss stuff or to commit it in some form so it would be public? -Karen Arved Sandstrom wrote: Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) As far as the Unicode bidi algorithm is concerned, yup, no kidding. :-) Have you looked at the Java reference implementation for it? :-) Not a trivial thing. Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 26, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: line layout commit Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. The main things that need thinking about are: - range properties - wrapping (ie. no wrap) - whitespace and linefeed handling - Unicode BIDI (this looks hard) It is very rough at the moment, the idea is to get a basis so that inline areas can be created and put into line areas and this will fit into the overall design. This leaves us with a simpler way of handing inline areas. So whats next? It is possible to start looking at fully implementing inline areas, eg. image, instream-foreign-object, leader, character. Getting pagination working will be a big step forward. Then we need to block area layout managers, like tables and lists. So what do people think? Regards, Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - 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/hyph pt.xml tr.xml
chrisg 02/04/26 16:19:22 Modified:.Tag: fop-0_20_2-maintain CHANGES Added: hyph Tag: fop-0_20_2-maintain pt.xml tr.xml Log: - Added turkish hyphenation patterns Submitted by: Togan Muftuoglu [EMAIL PROTECTED] - Aportuguese hyphenation patterns Submitted by: Paulo Soares [EMAIL PROTECTED] Revision ChangesPath No revision No revision 1.10.2.12 +4 -0 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.11 retrieving revision 1.10.2.12 diff -u -r1.10.2.11 -r1.10.2.12 --- CHANGES 25 Apr 2002 22:12:13 - 1.10.2.11 +++ CHANGES 26 Apr 2002 23:19:22 - 1.10.2.12 @@ -8,6 +8,10 @@ (ant-optional.jar is no longer needed) - Changed build.sh to work under cygwin Submitted by: Andriy Palamarchuk [EMAIL PROTECTED] +- Added turkish hyphenation patterns + Submitted by: Togan Muftuoglu [EMAIL PROTECTED] +- Aportuguese hyphenation patterns + Submitted by: Paulo Soares [EMAIL PROTECTED] == Done since 0.20.2 release *** General No revision No revision 1.1.2.1 +0 -0 xml-fop/hyph/pt.xml Index: pt.xml === RCS file: /home/cvs/xml-fop/hyph/pt.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.1.2.1 +0 -0 xml-fop/hyph/tr.xml Index: tr.xml === RCS file: /home/cvs/xml-fop/hyph/tr.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up bugzilla and next maintenance release
J.Pietschmann wrote: Hi committers, as you probably noticed, i started to rummage around in Bugzilla, searching for bugs still in existence and learning more about current and persistent problems. Great work, I hope I can help a bit soon. [..] Questions: Will there be another maintenance release before something comes out of the redesign? Yes, why not ;-) We already have improved logging, JAXP, background-image support, new hyphenation patterns. If so, when? Roadmap? I'd say in some weeks (don't know when batik 1.5 is ready) and IMHO setting deadlines doesn't work very well in open source projects where most developers do the work in their (limited) spare time. If so, which should be the problems solved? Pick from above or add whatever you think should be added. Top of my todo list: -Upgrade xercex/xalan -EBCDIC patch -check infinite loops with tables (I think there are still problems) -links in static content -test with docbook stylesheets Further question: Is the duplicate id bug fixed in all its incarnations? Example from bug #3007 works, bug #3497 still exists.. I'll put this on my todo list if no one else volunteers Oops: The FAQ goes along slowly, as usual. Converted to the FAQ-with-sections DTD referenced recently on the forrest-dev list. Will this be merged with the FAQ from Alex ? Thanks J.Pietschmann Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Editable image formats
Developers all, I have taken to using xfig for my design diagrams, and I would like to include an editable form of the images in the CVS. xfig will export Postscript, Encapsulated Postscript, PDF, LaTeX, IBM/HPGL, T/PIC, CGM, but not SVG. Are any of those suitable for downline vector editing? Peter P.S. What's the difference between PS and EPS? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
K, K, A and other developers, Regular chat sessions would probably have been useful here, and I think that they might still be useful. Probably every interested party but me is in the time zone spanned by Keiron and Arved. Anyone in the US? It should be possible for you to arrange some times. I would love to eavesdrop, and I would try to attend. What times would suit the three of you? Do you think it would be useful? Peter Karen Lease wrote: Hi Keiron, On the one hand, I'm happy to see new work in the LayoutManagers. On the other hand, it turns out, I have been plugging (unfortunately really slowly) away at the Break Possibility ideas I mentioned a while back and just this very evening I had gotten the Line and Text LayoutManagers to where they were actually generating areas based on the BreakPoss ... and maybe it was ready for CVS. ... really I'm not kidding. That was when I discovered that you had beat me to it by a few hours. I only saw your thinking aloud mail last night and my feeling was that apart from the flattening of inline LM idea, there might not be such a big difference in our approaches. But of course, the code itself is quite different. Arved Sandstrom wrote: Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PCL renderer limitations
checkout www.netlingo.com -- David B. Bitton[EMAIL PROTECTED]www.codenoevil.com Code Made Fresh Daily - Original Message - From: Art Welch To: '[EMAIL PROTECTED]' Sent: Friday, April 26, 2002 2:59 PM Subject: RE: PCL renderer limitations If the PDFRenderercenters the image properlyand the PCLRenderer does not then it is probably a bug in FOP (likely the PCLRenderer) not a problem with the FO code. Art -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 2:11 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitations [EMAIL PROTECTED] type="cite"> If the image is totally off center, then the problem is probably not related to scaling. "IIRC images", sorry I should have included a comma in there as in: "If I remember correctly, images..." It seems a bit odd to me that the PDF renderer would center the image properly and the PCL renderer would not center it at all. I have not looked at the code in a long time, but I thought that FOP did all the layout before calling the renderer. So it should just be saying "put the image here" and supplying the appropriate coordinates to the renderer. But it is entirely possible that this had changed - or perhaps even more likely - I am not remembering correctly. I have not looked at FOP code much since the redesign started. Okay... If you have time on your hands next week, I can send my fo code to the list.I have to leave now (8pm here), so ... have a nice week-end.Thanks for the answers, including the ones about shorthands ;-)Bruno Verachten.
Insufficient Karma!
Fop-devs, I just tried to commit a file I had added. Result: Access denied: Insufficient Karma (pbwest|xml-fop/docs/design/alt.design) cvs server: Pre-commit check failed It looks to have something to do with the avail file, and access to a resource called 'id'. Any ideas? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
