[RT] Proprietary extension to fo:external-graphic
While investigating the multi-threading issues in the maint-branch I came across the following: Currently, in the context of the PDF renderer, every FopImage is closed as soon as it's written to the target file. The next time the same image/url is used it has to be reloaded. This is not true for the other renderers, where the images are really being cached. The calls to FopImage.close() in PDFXObject are effectively disabling the caching mechanism. But on the other side it enables the correct working of urls that deliver dynamic content (only for PDFs), when the same URL can deliver different content over multiple invocations. Which brings me to my idea. I don't know if we had that before. Wouldn't it solve this problem if we defined a proprietary extension for fo:external-graphic to specify if a given url is not to be cached? The content-type attribute can obviously not be used for that purpose. How about this? fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ Default for disable-caching would be false. This could also be useful for the redesign, where we have the same problem: When can and should we cache an image? Currently, I'm thinking if I should just delete the FopImage.close() method, so the behaviour of image handling is the same for all renderers, but that results in a semantic change for the PDF renderer. To still be able to serve dynamic images the above would be necessary. Any thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13406] - Using padding displaces basic-link
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=13406. 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=13406 Using padding displaces basic-link --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 09:18 --- I found the same problem within a table. As a workaround I added 'space' blocks in the cell fo:table-cell border-width=0.1pt border-style=solid !-- padding-top=5pt padding-bottom=5pt -- fo:block space-before.optimum=5pt/fo:block fo:block fo:basic-link color=blue xsl:attribute name=internal-destination xsl:value-of select=BusinessObject/Row/GLOBAL_ID/ /xsl:attribute xsl:value-of select=BusinessObject/Row/GLOBAL_ID/ /fo:basic-link /fo:block fo:block space-after=5pt/fo:block /fo:table-cell David Gilby [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14290] New: - strokeSVGText=false causes space characters to be rendered incorrectly
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=14290. 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=14290 strokeSVGText=false causes space characters to be rendered incorrectly Summary: strokeSVGText=false causes space characters to be rendered incorrectly Product: Fop Version: 0.20.4 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: svg AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Use a config file in which strokeSVGText is set to false i.e. the config file contains: entry keystrokeSVGText/key valuefalse/value /entry Also supply any embedded font with a generated xml metrics file e.g. fonts font metrics-file=fonts/MSMincho.xml kerning=yes embed- file=fonts/msmincho.ttf font-triplet name=ChosenFont style=normal weight=normal/ /font /fonts Using the fo shown below to produce a pdf file results in no-break space (unicode 160 / 00A0) characters being rendered as capital 'O's and space (unicode 32 / 0020) characters being rendered as capital 'L's. Also, if the first line of text is commented out, then the pdf file created will be correct (i.e. spaces are spaces). Finally, if the frist line of text remains commented out and the leading capital 'O' is deleted from the beginning of the second line of text, the resulting pdf file has spaces rendered as boxes. Note that this problem was raised in the mail list archive here: http://marc.theaimsgroup.com/?l=fop-userm=103013719216193w=2 - ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=default page-height=11in page-width=8.5in fo:region-body margin-top=0.5in margin- bottom=0.5in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=default fo:flow flow-name=xsl-region-body fo:block fo:instream-foreign-object svg xmlns=http://www.w3.org/2000/svg; width=540 height=648 text x=57 y=43 style=font- family:ChosenFont;font-weight:normal;font-style:normal;font-size:12 nobreakspace:#160;regularspace:#32;EndOfLine/text text x=57 y=103 style=font-family:ChosenFont;font-weight:normal;font-style:normal;font- size:12 O no problem if this is the only line/text /svg /fo:instream-foreign-object /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/fo/pagination PageSequence.java
keiron 2002/11/06 02:02:29
Modified:src/org/apache/fop/layoutmgr PageLayoutManager.java
src/org/apache/fop/fo/pagination PageSequence.java
Log:
layout correct static region
improved docs and style
Revision ChangesPath
1.23 +129 -27 xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java
Index: PageLayoutManager.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- PageLayoutManager.java4 Nov 2002 11:50:11 - 1.22
+++ PageLayoutManager.java6 Nov 2002 10:02:28 - 1.23
@@ -8,7 +8,18 @@
package org.apache.fop.layoutmgr;
import org.apache.fop.apps.FOPException;
-import org.apache.fop.area.*;
+import org.apache.fop.area.AreaTree;
+import org.apache.fop.area.Area;
+import org.apache.fop.area.PageViewport;
+import org.apache.fop.area.Flow;
+import org.apache.fop.area.RegionViewport;
+import org.apache.fop.area.RegionReference;
+import org.apache.fop.area.BodyRegion;
+import org.apache.fop.area.MainReference;
+import org.apache.fop.area.Span;
+import org.apache.fop.area.BeforeFloat;
+import org.apache.fop.area.Footnote;
+import org.apache.fop.area.Resolveable;
import org.apache.fop.fo.flow.StaticContent;
import org.apache.fop.fo.pagination.PageSequence;
import org.apache.fop.fo.pagination.Region;
@@ -16,6 +27,8 @@
import org.apache.fop.fo.pagination.PageNumberGenerator;
import org.apache.fop.fo.properties.Constants;
+import org.apache.fop.area.MinOptMax;
+
import java.util.ArrayList;
import java.util.List;
@@ -26,9 +39,9 @@
public class PageLayoutManager extends AbstractLayoutManager implements Runnable {
private static class BlockBreakPosition extends LeafPosition {
-BreakPoss breakps;
+protected BreakPoss breakps;
-BlockBreakPosition(LayoutManager lm, BreakPoss bp) {
+protected BlockBreakPosition(LayoutManager lm, BreakPoss bp) {
super(lm, 0);
breakps = bp;
}
@@ -37,6 +50,7 @@
private PageNumberGenerator pageNumberGenerator;
private int pageCount = 1;
private String pageNumberString;
+private boolean isFirstPage = true;
/** True if haven't yet laid out any pages.*/
private boolean bFirstPage;
@@ -68,6 +82,9 @@
/**
* This is the top level layout manager.
* It is created by the PageSequence FO.
+ *
+ * @param areaTree the area tree to add pages to
+ * @param pageseq the page sequence fo
*/
public PageLayoutManager(AreaTree areaTree, PageSequence pageseq) {
super(pageseq);
@@ -75,12 +92,26 @@
pageSequence = pageseq;
}
+/**
+ * Set the page counting for this page sequence.
+ * This sets the initial page number and the page number formatter.
+ *
+ * @param pc the starting page number
+ * @param generator the page number generator
+ */
public void setPageCounting(int pc, PageNumberGenerator generator) {
pageCount = pc;
pageNumberGenerator = generator;
pageNumberString = pageNumberGenerator.makeFormattedPageNumber(pageCount);
}
+/**
+ * Get the page count.
+ * Used to get the last page number for reference for
+ * the next page sequence.
+ *
+ * @return the page number
+ */
public int getPageCount() {
return pageCount;
}
@@ -99,7 +130,12 @@
flush();
}
-public void doLayout() {
+/**
+ * Do the layout of this page sequence.
+ * This completes the layout of the page sequence
+ * which creates and adds all the pages to the area tree.
+ */
+protected void doLayout() {
// this should be done another way
makeNewPage(false, false);
@@ -123,7 +159,14 @@
pageCount--;
}
-
+/**
+ * Get the next break possibility.
+ * This finds the next break for a page which is always at the end
+ * of the page.
+ *
+ * @param context the layout context for finding breaks
+ * @return the break for the page
+ */
public BreakPoss getNextBreakPoss(LayoutContext context) {
LayoutManager curLM ; // currently active LM
@@ -147,10 +190,24 @@
return null;
}
+/**
+ * Get the current page number string.
+ * This returns the formatted string for the current page.
+ *
+ * @return the formatted page number string
+ */
public String getCurrentPageNumber() {
return pageNumberString;
}
+/**
+ * Resolve a reference ID.
+ * This resolves
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: Currently, in the context of the PDF renderer, every FopImage is closed as soon as it's written to the target file. The next time the same image/url is used it has to be reloaded. This is not true for the other renderers, where the images are really being cached. The calls to FopImage.close() in PDFXObject are effectively disabling the caching mechanism. But on the other side it enables the correct working of urls that deliver dynamic content (only for PDFs), when the same URL can deliver different content over multiple invocations. If we are talking about one particular formatting invokation scope, I don't think anybody would rely on dynamic image generation trying to place different images (while with the same URI) on a different pages. Acually the spec says nothing about it, but I believe it's up to formatter when/in which order/how much times to load images as it follows general xsl side-effect free policy. It's probably worth to check how other formatters cache images though. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Thanks for answering. Do you have a pointer to some documentation describing that side-effect free policy? So, do I get you right that the close() calls can safely be removed because the semantic change I described is irrelevant? That would be nice because it's easy to fix. On Wed, 06 Nov 2002 12:33:11 +0200 Oleg Tkachenko wrote: If we are talking about one particular formatting invokation scope, I don't think anybody would rely on dynamic image generation trying to place different images (while with the same URI) on a different pages. Acually the spec says nothing about it, but I believe it's up to formatter when/in which order/how much times to load images as it follows general xsl side-effect free policy. It's probably worth to check how other formatters cache images though. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Query!?
Hi, I have arial.xml,arialbd.xml,ariali.xml,arialbi.xml,ariblk.xml under my Fop-0.18.1-DEV dir. But during the XML to PDF convertions through XSL using XSLT processor, i am facing problem. The FO with font-family "Arial" whichused is not displayed after the PDF conversion. Does the Windows-NT and /or UNIX support these FONT-FAMILY? If yes, whats the procedure? and which are the required files ?And where can I get them from? Thanks. Do you Yahoo!? HotJobs - Search new jobs daily now
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote: . . . fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ . . . There are some fox: extensions already IIRC (never used them though, but http://xml.apache.org/fop/extensions.html says so), so I think new ones should be created in a consistent way. I'm ok with such extensions (we use similar things in jfor), just would like to make sure that there is only one extension mechanism. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14294] New: - [PATCH] awt viewer aggregate patch
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=14294. 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=14294 [PATCH] awt viewer aggregate patch Summary: [PATCH] awt viewer aggregate patch Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: awt renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] What I did: o synchronized the trunk with the branch by adopting up to yesterday improvements (reloading, go to page dialog l10n, latest czech and german updates etc.) o made l10n implementation using standard java Locale-aware PropertyResourceBundle facility, converted l10n resources to ascii-encoded properties files. o moved to using real keys for selecting localized strings. I mean translator.getString(Menu.Go.To.Page) instead of translator.getString(Go to Page). While that may look unnecessaryly, usage of keys improves l10n discipline as it requres from a developer to define each key value at least in a default bundle, so one never ever will have to look around the code to find out what labels can be localized in his language. o cleaned up the code, translated german comments o superfluous classes to be removed: UserMessage, MessageDialog, MessageException - as unused, SecureResourceBundle, LoadableProperties - in favor of java.util.ResourceBundle, IconToolBar - in favor of javax.swing.JToolBar, ProgressListener - as unused (it's a good idea to have formatting progress listener, but at least it shouldn't be defined in a viewer component), resources.* and messages.* - in favor new Viewer*.properties. o a very small adornments, like fop logo in the About dialog etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14294] - [PATCH] awt viewer aggregate patch
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=14294. 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=14294 [PATCH] awt viewer aggregate patch --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 11:54 --- Created an attachment (id=3754) diff against HEAD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14294] - [PATCH] awt viewer aggregate patch
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=14294. 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=14294 [PATCH] awt viewer aggregate patch --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 12:00 --- Created an attachment (id=3755) new images and resource bundles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
awt viewer revisited
Hello there! I have posted my awt viewer patch to the bugzilla patch queue. Please review. I tested the patch (english and russian languages only though) and it looks ok to me. PS.A bit of nitpicking: Images catalog looks bizarre among other packages, should be images. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Jeremias Maerki wrote: Thanks for answering. Do you have a pointer to some documentation describing that side-effect free policy? Unfortunately not. xsl requirements and xsl proposal states intensions for xsl to be side-effect free language, like its dad dsssl, but as side-effect free xslt is now a separate recommendation, xsl-fo is staying in its shadow. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wed, 2002-11-06 at 12:01, Bertrand Delacretaz wrote: On Wednesday 06 November 2002 09:55, Jeremias Maerki wrote: . . . fo:external-graphic src=url(http://localhost/mydynamicimage) xmlns:fop=http://xml.apache.org/fop; fop:disable-caching=true/ . . . There are some fox: extensions already IIRC (never used them though, but http://xml.apache.org/fop/extensions.html says so), so I think new ones should be created in a consistent way. That particular extension fox:... is for the pdf bookmarks. (ie. http://xml.apache.org/fop/extensions.pdf the pdf viewer should show the bookmarks) Currently the extension mechanism is only setup for handling xml elements and not for attributes. Anyone can add an extension and I don't really considered it an extension to FO unless you are doing some sort of fo tree/layout/areatree manipulation. I'm ok with such extensions (we use similar things in jfor), just would like to make sure that there is only one extension mechanism. What sort of jfor extensions are there, what do they do? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
font issues (was RE: Common code in CVS branches)
On Wed, 2002-11-06 at 08:09, Victor Mote wrote: I just went looking in the archives for this discussion thought I saw pieces of it, but could not find what I was looking for -- namely, what theories you guys had proposed / agreed upon. This is related to the font work that I have started, i.e. I assume that the problem is a difference between metrics reported/used by the awt Font and those reported from our parsed metrics files. If it is not too much trouble, do you mind recapping a brief summary of where the issue stands now? Thanks. It would be great if this information could be put somewhere for better issue tracking, bugzilla for example. Hopefully this could make it easier to locate and use when it is needed. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: forrest is coming?
On Tue, 2002-11-05 at 11:56, Oleg Tkachenko wrote: Hello there! I see forrest at the web site and it looks terrific! Well done, my congratulations. Sorry for predating any official announce :) Lots more to do but I think it is a good start. Need to brighten up or change the logo. Maybe we should have a competition. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
On Wednesday 06 November 2002 12:31, Keiron Liddle wrote: . . . What sort of jfor extensions are there, what do they do? We have jfor:style to define RTF styles (similar to CSS classes in concept) on the generated RTF elements. A concept that does not exist in XSL-FO as it doesn't make sense when generating printable documents. And also jfor:cmd to set options for the jfor processor, currently used for special tricks/hacks for keep-with stuff. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: forrest is coming?
On Wednesday 06 November 2002 10:03, Keiron Liddle wrote: . . . Lots more to do but I think it is a good start. Great job indeed! I've also been looking at Forrest more closely recently, already very usable and looks even more promising. Need to brighten up or change the logo. Maybe we should have a competition. Good idea, make sure you announce it on fop-users too if you decide to do it. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: awt viewer revisited
On Wed, 2002-11-06 at 13:12, Oleg Tkachenko wrote: Hello there! I have posted my awt viewer patch to the bugzilla patch queue. Please review. I tested the patch (english and russian languages only though) and it looks ok to me. Great! I'll take a look at see it in action. PS.A bit of nitpicking: Images catalog looks bizarre among other packages, should be images. I think the java standard is packages are always lower case, so it is wrong. A bit difficult to change as some OS's can't handle case in directories. Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
feature request queue
Hello there! Patch queue looks very good, and what about introducing one more queue for feature requests? We can identify them among other bugzilla entries by something like [FREQ] in a subject line. Last hour I noticed 3 small requests to be considered, but my monitor is full of those to do sticky notes already. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: feature request queue
On Wednesday 06 November 2002 14:58, Oleg Tkachenko wrote: . . . Patch queue looks very good, and what about introducing one more queue for feature requests? . . . I think these can be identified by the severity=enhancement field of bugzilla issues, isn't that sufficient? Maybe this must be documented on http://xml.apache.org/fop/bugs.html, adding a comment make sure to set severity=enhancement if you're entering a feature request? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: awt viewer revisited
On Wed, 2002-11-06 at 14:45, Keiron Liddle wrote: On Wed, 2002-11-06 at 13:12, Oleg Tkachenko wrote: Hello there! I have posted my awt viewer patch to the bugzilla patch queue. Please review. I tested the patch (english and russian languages only though) and it looks ok to me. Great! I'll take a look at see it in action. Looks good. I'll commit that. I had a few problems with character encoding and line endings so check that it is right. But it is good to see that the properties are in unicode now. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/viewer/resources Viewer.properties Viewer_cs.properties Viewer_de.properties Viewer_fi.properties Viewer_fr.properties Viewer_it.properties Viewer_ja.properties Viewer_pl.properties Viewer_ru.properties messages.de messages.en resources.de resources.en resources.fi resources.fr resources.it resources.pl resources.ru
keiron 2002/11/06 06:30:16
Modified:src/org/apache/fop/apps AWTStarter.java
src/org/apache/fop/render/awt AWTRenderer.java
src/org/apache/fop/viewer Command.java GoToPageDialog.java
PreviewDialog.java PreviewDialogAboutBox.java
Translator.java
Added: src/org/apache/fop/viewer/Images fop.gif reload.gif
src/org/apache/fop/viewer/resources Viewer.properties
Viewer_cs.properties Viewer_de.properties
Viewer_fi.properties Viewer_fr.properties
Viewer_it.properties Viewer_ja.properties
Viewer_pl.properties Viewer_ru.properties
Removed: src/org/apache/fop/viewer IconToolBar.java
LoadableProperties.java MessageException.java
MessagesDialog.java ProgressListener.java
SecureResourceBundle.java UserMessage.java
src/org/apache/fop/viewer/resources messages.de messages.en
resources.de resources.en resources.fi resources.fr
resources.it resources.pl resources.ru
Log:
awt viewer improvements
uses java PropertyResourceBundle for locale strings
cleaned up code and removed old classes
other small improvements
Submitted by: Oleg Tkachenko [EMAIL PROTECTED]
Revision ChangesPath
1.16 +41 -109 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.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- AWTStarter.java 25 Oct 2002 09:29:39 - 1.15
+++ AWTStarter.java 6 Nov 2002 14:30:15 - 1.16
@@ -6,136 +6,84 @@
*/
package org.apache.fop.apps;
-/*
- * originally contributed by
- * Juergen Verwohlt: [EMAIL PROTECTED],
- * Rainer Steinkuhle: [EMAIL PROTECTED],
- * Stanislav Gorkhover: [EMAIL PROTECTED]
- * Modified to use streaming API by Mark Lillywhite, [EMAIL PROTECTED]
- */
-import org.apache.fop.viewer.*;
-import org.apache.fop.render.awt.*;
+//FOP
+import org.apache.fop.render.awt.AWTRenderer;
+import org.apache.fop.viewer.PreviewDialog;
+import org.apache.fop.viewer.Translator;
+//Java
import javax.swing.UIManager;
import java.awt.*;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
+import java.util.Locale;
// SAX
import org.xml.sax.XMLReader;
-import org.xml.sax.InputSource;
-import org.xml.sax.SAXException;
-import org.xml.sax.SAXParseException;
-
-
-
-// Java
-import java.io.FileReader;
-import java.io.File;
-import java.io.FileWriter;
-import java.io.PrintWriter;
-import java.io.IOException;
-import java.io.FileNotFoundException;
-import java.io.FileInputStream;
-import java.io.InputStream;
-import java.net.URL;
-import java.util.*;
-
/**
- * initialize AWT previewer
+ * AWT Viewer starter.
+ * Originally contributed by:
+ * Juergen Verwohlt: [EMAIL PROTECTED],
+ * Rainer Steinkuhle: [EMAIL PROTECTED],
+ * Stanislav Gorkhover: [EMAIL PROTECTED]
+ * Modified to use streaming API by Mark Lillywhite, [EMAIL PROTECTED]
*/
public class AWTStarter extends CommandLineStarter {
+private PreviewDialog frame;
+private Translator translator;
+private Driver driver;
+private XMLReader parser;
-PreviewDialog frame;
-AWTRenderer renderer;
-public static String TRANSLATION_PATH =
-/org/apache/fop/viewer/resources/;
-
-private Translator resource;
-
-public AWTStarter(CommandLineOptions commandLineOptions)
-throws FOPException {
+public AWTStarter(CommandLineOptions commandLineOptions) throws FOPException {
super(commandLineOptions);
init();
}
-private void init() {
-try {
-UIManager.setLookAndFeel(new javax.swing.plaf.metal.MetalLookAndFeel());
-} catch (Exception e) {
-e.printStackTrace();
-}
-
+private void init() throws FOPException {
+//Creates Translator according to the language
String language = commandLineOptions.getLanguage();
-
-if (language == null) {
-try {
-language = System.getProperty(user.language);
-} catch(SecurityException se) {
-// if this is running in a secure place
-}
-}
-resource = getResourceBundle(TRANSLATION_PATH + resources.
- + language);
-
-UserMessage.setTranslator(getResourceBundle(TRANSLATION_PATH
- + messages.
- + language));
-
DO NOT REPLY [Bug 14294] - [PATCH] awt viewer aggregate patch
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=14294. 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=14294 [PATCH] awt viewer aggregate patch [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 14:53 --- Patch applied to HEAD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/area/inline Viewport.java
keiron 2002/11/06 07:07:04
Modified:src/org/apache/fop/area Area.java RegionViewport.java
src/org/apache/fop/area/inline Viewport.java
Log:
clone and serialize area traits
Revision ChangesPath
1.12 +6 -2 xml-fop/src/org/apache/fop/area/Area.java
Index: Area.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/Area.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Area.java 25 Oct 2002 09:29:39 - 1.11
+++ Area.java 6 Nov 2002 15:07:04 - 1.12
@@ -105,7 +105,11 @@
private int areaClass = CLASS_NORMAL;
private int ipd;
-private HashMap props = null;
+
+/**
+ * Traits for this area stored in a HashMap
+ */
+protected HashMap props = null;
/**
* Get the area class of this area.
1.6 +7 -1 xml-fop/src/org/apache/fop/area/RegionViewport.java
Index: RegionViewport.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/RegionViewport.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RegionViewport.java 18 Sep 2002 13:50:13 - 1.5
+++ RegionViewport.java 6 Nov 2002 15:07:04 - 1.6
@@ -9,6 +9,7 @@
import java.awt.geom.Rectangle2D;
import java.io.IOException;
+import java.util.HashMap;
/**
* Region Viewport reference area.
@@ -72,6 +73,7 @@
out.writeFloat((float) viewArea.getWidth());
out.writeFloat((float) viewArea.getHeight());
out.writeBoolean(clip);
+out.writeObject(props);
out.writeObject(region);
}
@@ -80,6 +82,7 @@
viewArea = new Rectangle2D.Float(in.readFloat(), in.readFloat(),
in.readFloat(), in.readFloat());
clip = in.readBoolean();
+props = (HashMap)in.readObject();
setRegion((RegionReference) in.readObject());
}
@@ -92,6 +95,9 @@
public Object clone() {
RegionViewport rv = new RegionViewport((Rectangle2D)viewArea.clone());
rv.region = (RegionReference)region.clone();
+if(props != null) {
+rv.props = (HashMap)props.clone();
+}
return rv;
}
}
1.5 +4 -1 xml-fop/src/org/apache/fop/area/inline/Viewport.java
Index: Viewport.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/inline/Viewport.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Viewport.java 18 Sep 2002 13:50:14 - 1.4
+++ Viewport.java 6 Nov 2002 15:07:04 - 1.5
@@ -12,6 +12,7 @@
import java.io.IOException;
import java.awt.geom.Rectangle2D;
+import java.util.HashMap;
/**
* Inline viewport area.
@@ -100,6 +101,7 @@
out.writeFloat((float) contentPosition.getHeight());
}
out.writeBoolean(clip);
+//out.writeObject(props);
out.writeObject(content);
}
@@ -112,6 +114,7 @@
in.readFloat());
}
clip = in.readBoolean();
+//props = (HashMap) in.readObject();
content = (Area) in.readObject();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
interface instead of implementation
Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern: import java.util.List; [..] private List myvalues = new java.util.ArrayList(); ArrayList never gets imported. That makes it easier to switch between implementation, for example if you have to switch between the unsynchronized ArrayList and the synchronized Vector. The decision which implementation to take should happen at one place in the code, not at many places. For Map there exist new implementations in Jakarta Commons Collections, for example. A method that takes List parameters (instead of ArrayList) is more universal. Thank you all! On 6 Nov 2002 15:07:04 - keiron wrote: + +/** + * Traits for this area stored in a HashMap + */ +protected HashMap props = null; Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Wednesday 06 November 2002 16:18, Jeremias Maerki wrote: . . . would you mind using the interface instead of the implementation where possible? big +1. The only drawback is when you need to clone Collections, but the benefits far outweigh this I think. Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
On Wed, 6 Nov 2002 16:25:24 +0100 Bertrand Delacretaz wrote: On Wednesday 06 November 2002 16:18, Jeremias Maerki wrote: . . . would you mind using the interface instead of the implementation where possible? big +1. Thanks for your support. The only drawback is when you need to clone Collections, but the benefits far outweigh this I think. I agree. Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? We've discussed coding style issues a few weeks ago. But we still haven't hammered anything down, I think. Still on my todo list. I'll have time for this in two or three weeks. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: interface instead of implementation
I wholeheartedly agree. This is really just good style in general. Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] Sent: Wednesday, November 06, 2002 10:19 AM To: [EMAIL PROTECTED] Subject: interface instead of implementation Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern: import java.util.List; [..] private List myvalues = new java.util.ArrayList(); ArrayList never gets imported. That makes it easier to switch between implementation, for example if you have to switch between the unsynchronized ArrayList and the synchronized Vector. The decision which implementation to take should happen at one place in the code, not at many places. For Map there exist new implementations in Jakarta Commons Collections, for example. A method that takes List parameters (instead of ArrayList) is more universal. Thank you all! On 6 Nov 2002 15:07:04 - keiron wrote: + +/** + * Traits for this area stored in a HashMap + */ +protected HashMap props = null; Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Bertrand Delacretaz wrote: Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? Some time ago Jeremias has promised us that already :) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/pdf PDFRenderer.java
keiron 2002/11/06 07:36:29
Modified:src/org/apache/fop/fo/pagination Region.java RegionBody.java
src/org/apache/fop/layoutmgr AbstractLayoutManager.java
src/org/apache/fop/render AbstractRenderer.java
src/org/apache/fop/render/pdf PDFRenderer.java
Log:
background and borders for regions
Revision ChangesPath
1.13 +33 -14xml-fop/src/org/apache/fop/fo/pagination/Region.java
Index: Region.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/pagination/Region.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Region.java 25 Oct 2002 09:29:43 - 1.12
+++ Region.java 6 Nov 2002 15:36:28 - 1.13
@@ -22,6 +22,7 @@
import org.apache.fop.area.CTM;
import org.apache.fop.area.RegionViewport;
import org.apache.fop.area.RegionReference;
+import org.apache.fop.layoutmgr.AbstractLayoutManager;
import org.xml.sax.Attributes;
@@ -82,9 +83,29 @@
Rectangle2D absRegionRect = pageCTM.transform(relRegionRect);
// Get the region viewport rectangle in absolute coords by
// transforming it using the page CTM
-return new RegionViewport(absRegionRect);
+RegionViewport rv = new RegionViewport(absRegionRect);
+setRegionViewportTraits(rv);
+return rv;
}
+/**
+ * Set the region viewport traits.
+ * The viewport has the border, background and
+ * clipping overflow traits.
+ *
+ * @param r the region viewport
+ */
+protected void setRegionViewportTraits(RegionViewport r) {
+// Common Border, Padding, and Background Properties
+BorderAndPadding bap = propMgr.getBorderAndPadding();
+BackgroundProps bProps = propMgr.getBackgroundProps();
+AbstractLayoutManager.addBorders(r, bap);
+AbstractLayoutManager.addBackground(r, bProps);
+
+// this.properties.get(clip);
+// this.properties.get(display-align);
+this.overflow = this.properties.get(overflow).getEnum();
+}
protected abstract Rectangle getViewportRectangle(FODimension pageRefRect);
@@ -96,23 +117,21 @@
*/
public RegionReference makeRegionReferenceArea(Rectangle2D absRegVPRect) {
RegionReference r = new RegionReference(getRegionAreaClass());
-setRegionTraits(r, absRegVPRect);
+setRegionPosition(r, absRegVPRect);
return r;
}
-protected void setRegionTraits(RegionReference r, Rectangle2D absRegVPRect) {
-// Common Border, Padding, and Background Properties
-BorderAndPadding bap = propMgr.getBorderAndPadding();
-BackgroundProps bProps = propMgr.getBackgroundProps();
-/*backgroundColor = properties.get(background-color).getColorType();*/
-
-// this.properties.get(clip);
-// this.properties.get(display-align);
-this.overflow = this.properties.get(overflow).getEnum();
+/**
+ * Set the region position inside the region viewport.
+ * This sets the trasnform that is used to place the contents of
+ * the region.
+ *
+ * @param r the region reference area
+ * @param absRegVPRect the rectangle to place the region contents
+ */
+protected void setRegionPosition(RegionReference r, Rectangle2D absRegVPRect) {
FODimension reldims = new FODimension(0,0);
r.setCTM(propMgr.getCTMandRelDims(absRegVPRect, reldims));
-
-//r.setBackground(bProps);
}
/**
1.19 +2 -9 xml-fop/src/org/apache/fop/fo/pagination/RegionBody.java
Index: RegionBody.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/pagination/RegionBody.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- RegionBody.java 7 Aug 2002 16:54:57 - 1.18
+++ RegionBody.java 6 Nov 2002 15:36:28 - 1.19
@@ -65,17 +65,10 @@
return ((prop != null)? prop.getLength().mvalue() : 0);
}
-protected void setRegionTraits(RegionReference r, Rectangle2D absRegVPRect) {
-super.setRegionTraits(r, absRegVPRect);
-
-// r.setBackgroundColor(backgroundColor);
-}
-
protected String getDefaultRegionName() {
return xsl-region-body;
}
-
public String getRegionClass() {
return Region.BODY;
}
@@ -90,7 +83,7 @@
public RegionReference makeRegionReferenceArea(Rectangle2D absRegVPRect) {
// Should set some column stuff here I think, or put it elsewhere
BodyRegion body = new BodyRegion();
-setRegionTraits(body, absRegVPRect);
+setRegionPosition(body,
RE: interface instead of implementation
Well, if he needs help getting it done, I'm available. -Original Message- From: Oleg Tkachenko [mailto:olegt;multiconn.com] Sent: Wednesday, November 06, 2002 10:32 AM To: [EMAIL PROTECTED] Subject: Re: interface instead of implementation Bertrand Delacretaz wrote: Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? Some time ago Jeremias has promised us that already :) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr/table Body.java Caption.java Cell.java Row.java TableAndCaptionLayoutManager.java
keiron 2002/11/06 07:46:55
Modified:src/org/apache/fop/layoutmgr
BlockContainerLayoutManager.java
src/org/apache/fop/layoutmgr/list Item.java
ListBlockLayoutManager.java
ListItemLayoutManager.java
src/org/apache/fop/layoutmgr/table Body.java Caption.java
Cell.java Row.java
TableAndCaptionLayoutManager.java
Log:
some minor improvements to make layout work a bit better
Revision ChangesPath
1.4 +15 -15
xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
Index: BlockContainerLayoutManager.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BlockContainerLayoutManager.java 13 Sep 2002 08:21:54 - 1.3
+++ BlockContainerLayoutManager.java 6 Nov 2002 15:46:55 - 1.4
@@ -58,7 +58,7 @@
propManager = pm;
abProps = pm.getAbsolutePositionProps();
-if(abProps.absolutePosition == AbsolutePosition.ABSOLUTE) {
+if (abProps.absolutePosition == AbsolutePosition.ABSOLUTE) {
Rectangle2D rect = new Rectangle2D.Double(abProps.left,
abProps.top, abProps.right - abProps.left,
abProps.bottom - abProps.top);
@@ -77,7 +77,7 @@
public BreakPoss getNextBreakPoss(LayoutContext context) {
-if(abProps.absolutePosition == AbsolutePosition.ABSOLUTE) {
+if (abProps.absolutePosition == AbsolutePosition.ABSOLUTE) {
return getAbsoluteBreakPoss(context);
}
@@ -90,13 +90,13 @@
MinOptMax stackLimit;
int ipd = context.getRefIPD();
boolean rotated = vals[0] == 0.0;
-if(rotated) {
+if (rotated) {
// rotated 90 degrees
stackLimit = new MinOptMax(100);
ipd = getRotatedIPD();
absoluteCTM = new CTM(vals[0], vals[1], vals[2], vals[3], 0, 0);
} else {
-if(vals[0] == -1.0) {
+if (vals[0] == -1.0) {
absoluteCTM = new CTM(vals[0], vals[1], vals[2], vals[3], 0, 0);
}
stackLimit = context.getStackLimit();
@@ -123,7 +123,7 @@
while (!curLM.isFinished()) {
if ((bp = curLM.getNextBreakPoss(childLC)) != null) {
stackSize.add(bp.getStackingSize());
-if (stackSize.min stackLimit.max) {
+if (stackSize.opt stackLimit.max) {
// reset to last break
if (lastPos != null) {
reset(lastPos.getPosition());
@@ -139,7 +139,7 @@
stackLimit, stackSize));
}
}
-if(!rotated) {
+if (!rotated) {
BreakPoss breakPoss;
breakPoss = new BreakPoss(new LeafPosition(this,
childBreaks.size() - 1));
@@ -148,7 +148,7 @@
}
}
setFinished(true);
-if(rotated) {
+if (rotated) {
BreakPoss breakPoss;
breakPoss = new BreakPoss(new LeafPosition(this,
childBreaks.size() - 1));
@@ -189,10 +189,10 @@
// to the normal stacking
breakPoss.setStackingSize(new MinOptMax(0));
-if(stackSize.min relDims.bpd) {
-if(overflow == Overflow.HIDDEN) {
+if (stackSize.opt relDims.bpd) {
+if (overflow == Overflow.HIDDEN) {
clip = true;
-} else if(overflow == Overflow.ERROR_IF_OVERFLOW) {
+} else if (overflow == Overflow.ERROR_IF_OVERFLOW) {
//log.error(contents overflows block-container viewport:
clipping);
clip = true;
}
@@ -230,7 +230,7 @@
public Area getParentArea(Area childArea) {
if (curBlockArea == null) {
viewportBlockArea = new BlockViewport();
-if(abProps.absolutePosition == AbsolutePosition.ABSOLUTE) {
+if (abProps.absolutePosition == AbsolutePosition.ABSOLUTE) {
viewportBlockArea.setXOffset(abProps.left);
viewportBlockArea.setYOffset(abProps.top);
viewportBlockArea.setWidth(abProps.right - abProps.left);
@@ -241,12 +241,12 @@
} else {
double[] vals = absoluteCTM.toArray();
boolean rotated = vals[0] == 0.0;
-
FOP developer's style guide? (Was: interface instead of implementation)
On Wednesday 06 November 2002 16:31, Rhett Aultman wrote: . . . Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. . . . How about using a wiki page (web page where everyone can very easily write and edit) to work together on a draft style guide. including links to existing guides so we don't reinvent the wheel? If I get some +1s on this I'll setup the page and publish its address here. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP developer's style guide? (Was: interface instead of implementation)
You get my +1. A Wiki for a draft, followed by a vote for commitment to a less malleable form, is the best way I could see for us to do this. -Original Message- From: Bertrand Delacretaz [mailto:bdelacretaz;codeconsult.ch] Sent: Wednesday, November 06, 2002 10:48 AM To: [EMAIL PROTECTED] Subject: FOP developer's style guide? (Was: interface instead of implementation) On Wednesday 06 November 2002 16:31, Rhett Aultman wrote: . . . Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. . . . How about using a wiki page (web page where everyone can very easily write and edit) to work together on a draft style guide. including links to existing guides so we don't reinvent the wheel? If I get some +1s on this I'll setup the page and publish its address here. -Bertrand - 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: interface instead of implementation
Hey, Rhett, that would be cool. But it involves reading through that whole discussion again, trying to find a common line and distill that into a nice little document. As I've said, I'll have time to do it, just not now. If you take it, THANKS A LOT! On Wed, 6 Nov 2002 10:37:12 -0500 Rhett Aultman wrote: Well, if he needs help getting it done, I'm available. -Original Message- From: Oleg Tkachenko [mailto:olegt;multiconn.com] Sent: Wednesday, November 06, 2002 10:32 AM To: [EMAIL PROTECTED] Subject: Re: interface instead of implementation Bertrand Delacretaz wrote: Maybe a minimal best practices or style guide document for developers would be nice, I don't think there is one already? Some time ago Jeremias has promised us that already :) I know, I know. :-) See my other mail. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP developer's style guide? (Was: interface instead of implementation)
+1 On Wed, 6 Nov 2002 16:48:11 +0100 Bertrand Delacretaz wrote: On Wednesday 06 November 2002 16:31, Rhett Aultman wrote: . . . Maybe we should seriously consider a FOP developer coding standard and start writing it down and putting it on the site. I'd offer to help with that. . . . How about using a wiki page (web page where everyone can very easily write and edit) to work together on a draft style guide. including links to existing guides so we don't reinvent the wheel? If I get some +1s on this I'll setup the page and publish its address here. -Bertrand Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/test/resources/fop/svg embed.fo
keiron 2002/11/06 07:57:11 Modified:test/resources/fop/image size.fo test/resources/fop/svg embed.fo Log: improved layout a bit, added some more examples of scaling Revision ChangesPath 1.2 +31 -4 xml-fop/test/resources/fop/image/size.fo Index: size.fo === RCS file: /home/cvs/xml-fop/test/resources/fop/image/size.fo,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- size.fo 5 Jul 2002 06:10:54 - 1.1 +++ size.fo 6 Nov 2002 15:57:10 - 1.2 @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=utf-8? -fo:root font-family=Times Roman font-size=12pt text-align=center xmlns:fo=http://www.w3.org/1999/XSL/Format; +fo:root font-family=Times Roman font-size=12pt xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master @@ -11,8 +11,8 @@ page-width=21cm page-height=29.7cm master-name=left - fo:region-before extent=1cm/ - fo:region-body margin-top=1cm/ + fo:region-before extent=0.5cm/ + fo:region-body margin-top=0.5cm margin-bottom=1.7cm/ fo:region-after extent=1.5cm/ /fo:simple-page-master @@ -27,7 +27,7 @@ /fo:static-content fo:flow flow-name=xsl-region-body -fo:block font-size=18pt font-weight=bold1. FOP test for images/fo:block +fo:block font-size=18pt font-weight=bold text-align=center1. FOP test for images/fo:block fo:block fo:block font-size=16pt font-weight=bold space-before.minimum=1em space-before.optimum=1.5em space-before.maximum=2emNormal/fo:block fo:block @@ -77,6 +77,33 @@ The image (fo:external-graphic width=50pt height=50pt overflow=error-if-overflow src=file:logo.jpg/) is clipped with the content size double the viewport size. +This has fo:inline font-style=italicerror-if-overflow/fo:inline +set so there should be an error reported, it can recover from the +error by clipping to the viewport. + /fo:block +/fo:block + +fo:block + fo:block font-size=16pt font-weight=bold space-before.minimum=1em space-before.optimum=1.5em space-before.maximum=2emScaling/fo:block + fo:block +The image +(fo:external-graphic content-width=100pt content-height=50pt scaling=non-uniform src=file:logo.jpg/) +has non-uniform scaling. + /fo:block + fo:block +The image +(fo:external-graphic content-width=50pt content-height=100pt scaling=non-uniform src=file:logo.jpg/) +has non-uniform scaling. + /fo:block + fo:block +The image +(fo:external-graphic content-width=100pt content-height=75pt scaling=uniform src=file:logo.jpg/) +has uniform scaling. + /fo:block + fo:block +The image +(fo:external-graphic content-width=75pt content-height=100pt scaling=uniform src=file:logo.jpg/) +has uniform scaling. /fo:block /fo:block 1.2 +6 -5 xml-fop/test/resources/fop/svg/embed.fo Index: embed.fo === RCS file: /home/cvs/xml-fop/test/resources/fop/svg/embed.fo,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- embed.fo 5 Jul 2002 09:20:13 - 1.1 +++ embed.fo 6 Nov 2002 15:57:11 - 1.2 @@ -3,7 +3,7 @@ !ENTITY svgimage SYSTEM blocks.ent ] -fo:root font-family=Times Roman font-size=12pt text-align=center xmlns:fo=http://www.w3.org/1999/XSL/Format; +fo:root font-family=Times Roman font-size=12pt xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master @@ -30,7 +30,7 @@ /fo:static-content fo:flow flow-name=xsl-region-body -fo:block font-size=18pt font-weight=boldEmbedding SVG in Viewport/fo:block +fo:block font-size=18pt font-weight=bold text-align=centerEmbedding SVG in Viewport/fo:block fo:block fo:block font-size=16pt font-weight=bold space-before.minimum=1em space-before.optimum=1.5em space-before.maximum=2emAlign in Larger Viewport/fo:block @@ -78,9 +78,10 @@ fo:block font-size=16pt font-weight=bold space-before.minimum=1em space-before.optimum=1.5em space-before.maximum=2emScaling/fo:block fo:block Non-uniform -(fo:instream-foreign-object content-width=100pt content-height=50pt scaling=non-uniform overflow=hidden text-align=startsvgimage;/fo:instream-foreign-object), uniform -(fo:instream-foreign-object content-width=100pt content-height=50pt scaling=uniform overflow=hidden text-align=startsvgimage;/fo:instream-foreign-object), uniform -(fo:instream-foreign-object content-width=50pt content-height=100pt scaling=uniform overflow=hidden text-align=startsvgimage;/fo:instream-foreign-object). +(fo:instream-foreign-object content-width=100pt content-height=50pt scaling=non-uniform overflow=hidden text-align=startsvgimage;/fo:instream-foreign-object), non-uniform
Re: FOP developer's style guide? (Was: interface instead ofimplementation)
On Wed, 2002-11-06 at 16:48, Bertrand Delacretaz wrote: How about using a wiki page (web page where everyone can very easily write and edit) to work together on a draft style guide. including links to existing guides so we don't reinvent the wheel? If I get some +1s on this I'll setup the page and publish its address here. +1 -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP developer's style guide? (Was: interface instead of implementation)
How about using a wiki page [ ... ] +1 -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Sorry, Keiron, for explicitly mentioning you. I was just working in the maint branch seeing all those ArrayLists (former Vectors) and HashMaps (former Hashtables) that are creeping through all the code. And then your CVS commit came... I know I can be an elephant in a porcelaine store sometimes. Sorry. Anyway, I intend to overtake you with style error fixing soon. :-) On 06 Nov 2002 16:43:06 +0100 Keiron Liddle wrote: Since I have removed over 3000 style errors you give me a bit of slack!! :) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP developer's style guide? (Was: interface instead of implementation)
Wow, that's a quick vote... I have setup the page at http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide with a most basic style guide skeleton. I have to run now, but feel free to work on it. Make sure you keep copies of what you write, I cannot guarantee backups on this server yet. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop status.xml
keiron 2002/11/06 08:25:17 Modified:.status.xml Log: updated a number of previous changes Revision ChangesPath 1.14 +35 -7 xml-fop/status.xml Index: status.xml === RCS file: /home/cvs/xml-fop/status.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- status.xml16 Oct 2002 17:01:56 - 1.13 +++ status.xml6 Nov 2002 16:25:17 - 1.14 @@ -39,15 +39,9 @@ /action action context=code dev=open Retrieve markers from page. - When doing the static areas the markers wil need to be available for + When doing the static areas the markers will need to be available for retrieving. The marker can then be layed out as normal. /action -action context=code dev=open - implement the caching mechanism to store pages - when a page contains a forward reference that has not been - resolved then we need to be able to save the page contents to - disk to save memory -/action action context=code dev=KLL Implement table layout. The table layout will use the same technique as the block layout. It @@ -123,6 +117,40 @@ changes release version=? date=2002 +action context=code dev=KLL type=update +due-to=Oleg Tkachenko due-to-email=[EMAIL PROTECTED] + Awt viewer improvements - uses java PropertyResourceBundle + for locale strings, cleaned up code and removed old classes + and other small improvements +/action +action context=code dev=KLL type=update + Started list layout implementation. +/action +action context=code dev=KLL type=update + Improved pagination and page number for page sequences. +/action +action context=code dev=KLL type=update + Implemented border and background for many areas. +/action +action context=code dev=KLL type=update + Started table layout implementation. +/action +action context=docs dev=KLL type=update +due-to=Victor Mote due-to-email=[EMAIL PROTECTED] + Added link for patch queue. +/action +action context=code dev=KLL type=update +due-to=Rainer Garus due-to-email=[EMAIL PROTECTED] + Fixed npe when a page has several forward links. + Use HashSet to store unresolved references (pages) in area tree + to prevent duplication. +/action +action context=code dev=KLL type=update + Implemented example caching mechanism to store pages. + When a page contains a forward reference that has not been + resolved then it can save the page contents to + disk to save memory. +/action action dev=CG type=add context=code due-to=Bernd Brandstetter due-to-email=[EMAIL PROTECTED] Linking to a specific page and a named destinations of an - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Showing FO output
Jeremias Maerki wrote: I'm going a step further and I'm thinking about providing a development tool for FOP. We've developed a simple one at work where we could specify either FO or XML/xSLT file and an output format (FO, PDF, PS etc.). Then we have that big Process button that runs the document through Xalan and FOP. The configuration is saved when you exit, but at the moment we don't have multiple profiles. I've got a few good ideas about an improved tool in this direction. It would also be a good project for someone who'd like to contribute to the FOP project but doesn't want to go to the depths. I can elaborate if anyone is interested. I agree with you, I was thinking about it too. btw, I found an interesting mail in the xsl-list archive back to 1999 from James Tauber about his vision of FOP's future[1]: To give a little insight into my *long term* vision for FOP. Eventually, I would like to put a GUI interface on top to allow exactly this kind of human fine-tuning. The FOP engine does an initial layout and then a human can override line/column/page breaks, hyphenation, kerning, etc., saving back as formatting objects again. Well, but 1.0dev certanly is higher in the task list. [1] http://www.biglist.com/lists/xsl-list/archives/199905/msg00504.html -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
HashMaps (WAS:RE: interface instead of implementation)
You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] Sent: Wednesday, November 06, 2002 11:10 AM To: [EMAIL PROTECTED] Subject: Re: interface instead of implementation Sorry, Keiron, for explicitly mentioning you. I was just working in the maint branch seeing all those ArrayLists (former Vectors) and HashMaps (former Hashtables) that are creeping through all the code. And then your CVS commit came... I know I can be an elephant in a porcelaine store sometimes. Sorry. Anyway, I intend to overtake you with style error fixing soon. :-) On 06 Nov 2002 16:43:06 +0100 Keiron Liddle wrote: Since I have removed over 3000 style errors you give me a bit of slack!! :) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HashMaps (WAS:RE: interface instead of implementation)
Mostly it was for caching benefits. As I said, though, I haven't read enough code to know. I just thought I'd throw it out as a possibile way to save on memory usage when FOP processes large documents. *shrug* ;) -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] Sent: Wednesday, November 06, 2002 1:38 PM To: [EMAIL PROTECTED] Subject: Re: HashMaps (WAS:RE: interface instead of implementation) For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
fo:external-graphic in PDF
This is how it used to work: o anywhere in FOP formatting - load image, if same URL was not loaded before and find out the space needed for the image. - keep list of processed files. o PDF Renderer: - generate XObject, if XObject of same URL was not generated before. Delete image buffer: partial image cleanup only? - keep list of generated XObjects. - reference/reuse the XObject as often as required in content streams, scaled to different sizes A simple design: o FOP formatting determines space needed = partial reading of image files o Renderers control image processing according to their needs. The PDF renderer does not need any caching: maximum 1 image in memory at a time. - additional attributes for external-graphic might be helpful, e.g. resolution, color model - Isolation image processing in renderers will solve SVG caching more easily. Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: awt viewer revisited
Keiron Liddle wrote: I had a few problems with character encoding and line endings so check that it is right. The code looks fine, but all Viewer*.property files seem to be CRCRLF-ed :( I have no idea why. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Proprietary extension to fo:external-graphic
Oleg Tkachenko wrote:
Jeremias Maerki wrote:
Thanks for answering. Do you have a pointer to some documentation
describing that side-effect free policy?
Unfortunately not. xsl requirements and xsl proposal states intensions
for xsl to be side-effect free language, like its dad dsssl, but as
side-effect free xslt is now a separate recommendation, xsl-fo is
staying in its shadow.
Well, XSLT explicitely specified that document() must always return
the same tree during a transformation run. It does not explicitely
say whether the source is only accessed once or multiple times, and,
quite predictable, Xalan accesses the referenced URL every time it
encounters a document() call (even though it seems to discard the
read tree in favor of the cached tree), while Saxon and libxslt
access the URL exactly once.
I think it would be prudent to follow the same for
fo:external-graphics and fo:color-profile, on the ground that
FOs may be rendered out of order and, even more important, it is
not clear whether multiple renderings of an external graphic in a
static content, table header/footer or a marker should result in
multiple access to the source. Unfortunately, the spec doesn't even
mention this issue.
Mind you, there was already a complaint where someone used a
fo:external-graphic in a page footer for images representing page
numbers and of course didn't get what he expected.
In XSLT, for document(), it can be argued that it should be easy to
arrange for an additional dummy parameter in order to have distinct
URLs, for example
xsl:value-of select=document('http://ts.com/get-time.cgi?start')/
xsl:call-template name=template-to-profile/
xsl:value-of select=document('http://ts.com/get-time.cgi?end')/
Of course, nothing prevents the XSLT processor from fetching both
values first and then going on with evaluating the template in between,
therefore this technique is risky at least.
A similar approach oviously wont work for fetching graphics repressenting
page numbers.
Conclusions and ideas so far:
- FOP should cache external graphics during a rendering and by default
clear the cache afterwards.
- Caching images across renderings definitely is an issue too (think of
the company logo in each page header in every document), but FOP shouldn't
solve this. I imagine a SourceResolver interface which gets an URL and
optional content type and returns a XMLReader/InputSource pair.
In case of binary image formats the default implementation returns a null
parser.
People who want to cache images across renderings can implement their
own resolver which can do the caching. The Cocoon crowd will certainly
rejoice (no more memory leaks due to FOP caching, access to Cocoon
caching and Cocoon internal pipelines and other advantages).
- Fine tuning: A single large image will block a lot of memory during
rendering. A possibility is a fox:cache=no control property. In order
to preserve semantics, a null image is cached for this URL, and an error
is generated in case it is attempted to render the image a second time.
- Dynamic URLs. In order to achive this, we can extend the functions available
in property expressions by concat() and page-number(). I believe both would
be welcome by many users for other purposes too (whether that't a good idea
is another matter). One of the possible concerns are usually name clashes
with future XSLFO extensions. Using prefixed identifiers like fox:concat()
would be a solution, I'm somewhat uneasy with using XML namespace mechanisms
within values for XML attributes. In fact, I think its abuse, but I can't
offer much better ideas either.
Regards
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Query!?
roopashree s wrote: I have arial.xml,arialbd.xml,ariali.xml,arialbi.xml,ariblk.xml under my Fop-0.18.1-DEV dir. But during the XML to PDF convertions through XSL using XSLT processor, i am facing problem. The FO with font-family Arial which used is not displayed after the PDF conversion. Does the Windows-NT and /or UNIX support these FONT-FAMILY? If yes, whats the procedure? and which are the required files ?And where can I get them from? You have to produce a userconfig.xml file which declares the fonts and use it with FOP. For more recent FOP versions this procedure is described in the documentation distributed with the binaries and the source, in docs/html-docs/fonts.html. It is strongly recommended to upgrade to the latest FOP release (0.20.4), the only exception being that you use the old API and can't change. The OS doesn't matter, except taht you probably can refer to the font directory on Windows directly, while you'll have to download the arial.ttf et al. files explicitely to the machine under Linux. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14319] New: - Three problems in custom font metrics-file and embed-file value
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=14319. 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=14319 Three problems in custom font metrics-file and embed-file value Summary: Three problems in custom font metrics-file and embed- file value Product: Fop Version: 0.20.4 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When specify a new font in userconfig.xml, there are three problems for metrices-file and embed-file attribute value. 1. The value is added none prefix if it is relativeURL and baseDIr has not been specified. 2. The protocol prefix of this value is stripped off. So, it cannot support non-file protocol. 3. It cannot support XML parser other than xerces if it requires protocol prefix for SystemId value in SAX interface implementation. All problems are in org.apache.fop.configuration.FontInfo class. Casper has report a workarround in Bug #12854. But prefered has solution for not stripping protocol part of this value in getMetricsFile() and getEmbedFile() method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
Rhett, Jeremias, I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Peter Rhett Aultman wrote: Mostly it was for caching benefits. As I said, though, I haven't read enough code to know. I just thought I'd throw it out as a possibile way to save on memory usage when FOP processes large documents. *shrug* ;) -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: interface instead of implementation
Jeremias, I have no objection at all, as long as it costs nothing. It is free, isn't it? Peter Jeremias Maerki wrote: Fellow FOP developers, would you mind using the interface instead of the implementation where possible? Map instead of HashMap, List instead of ArrayList. I've seen this habit in a number of places and not only by Keiron! I've made it a habit to follow this pattern ... -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/design - New directory
keiron 2002/11/06 23:31:55 xml-fop/src/documentation/content/xdocs/design - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt viewer revisited
On Wed, 06 Nov 2002 23:59:53 +0200 Oleg Tkachenko wrote: Keiron Liddle wrote: I had a few problems with character encoding and line endings so check that it is right. The code looks fine, but all Viewer*.property files seem to be CRCRLF-ed :( I have no idea why. That's a problem all over the maintenance branch. If you have UltraEdit it's easy to just load the file and make a conversion UNIX -- DOS. Sounds strange, but works fine here. That's the problem I described in the line ending chaos thread. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/viewer/resources Viewer.properties Viewer_cs.properties Viewer_de.properties Viewer_fi.properties Viewer_fr.properties Viewer_it.properties Viewer_ja.properties Viewer_pl.properties Viewer_ru.properties
keiron 2002/11/06 23:44:58 Modified:src/org/apache/fop/viewer/resources Viewer.properties Viewer_cs.properties Viewer_de.properties Viewer_fi.properties Viewer_fr.properties Viewer_it.properties Viewer_ja.properties Viewer_pl.properties Viewer_ru.properties Log: fixed line endings Revision ChangesPath 1.2 +44 -43xml-fop/src/org/apache/fop/viewer/resources/Viewer.properties Index: Viewer.properties === RCS file: /home/cvs/xml-fop/src/org/apache/fop/viewer/resources/Viewer.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Viewer.properties 6 Nov 2002 14:30:16 - 1.1 +++ Viewer.properties 7 Nov 2002 07:44:58 - 1.2 @@ -1,43 +1,44 @@ -# -# Copyright (C) The Apache Software Foundation. All rights reserved.# -# - # -# This software is published under the terms of the Apache Software License # -# version 1.1, a copy of which has been included with this distribution in # -# the LICENSE file. # -# -# -# AWT viewer's GUI resources. Default bundle. -# -Menu.File=File -Menu.Exit=Exit -Menu.View=View -Menu.First.page=First page -Menu.Prev.page=Previous page -Menu.Next.page=Next page -Menu.Last.page=Last page -Menu.Go.to.Page=Go to Page -Menu.Help=Help -Menu.Default.zoom=Default zoom -Menu.About=About -Menu.Print=Print -Menu.Zoom=Zoom -Menu.Reload=Reload - -Title.Preview=Preview - -Status.Show=Show -Status.Page=Page -Status.of=of -Status.Build.FO.tree=Build FO tree... - -Exception.Occured=An exception has occured -Exception.Error=Fatal error - -Label.Page.number=Page number -Button.Ok=Ok -Button.Cancel=Cancel - -About.Product=FOP AWT Viewer -About.Version=Version: -About.Copyright=See http://xml.apache.org/fop -About.Title=About \ No newline at end of file +# +# Copyright (C) The Apache Software Foundation. All rights reserved.# +# - # +# This software is published under the terms of the Apache Software License # +# version 1.1, a copy of which has been included with this distribution in # +# the LICENSE file. # +# +# +# AWT viewer's GUI resources. Default bundle. +# +Menu.File=File +Menu.Exit=Exit +Menu.View=View +Menu.First.page=First page +Menu.Prev.page=Previous page +Menu.Next.page=Next page +Menu.Last.page=Last page +Menu.Go.to.Page=Go to Page +Menu.Help=Help +Menu.Default.zoom=Default zoom +Menu.About=About +Menu.Print=Print +Menu.Zoom=Zoom +Menu.Reload=Reload + +Title.Preview=Preview + +Status.Show=Show +Status.Page=Page +Status.of=of +Status.Build.FO.tree=Build FO tree... + +Exception.Occured=An exception has occured +Exception.Error=Fatal error + +Label.Page.number=Page number +Button.Ok=Ok +Button.Cancel=Cancel + +About.Product=FOP AWT Viewer +About.Version=Version: +About.Copyright=See http://xml.apache.org/fop +About.Title=About + 1.2 +34 -34xml-fop/src/org/apache/fop/viewer/resources/Viewer_cs.properties Index: Viewer_cs.properties === RCS file: /home/cvs/xml-fop/src/org/apache/fop/viewer/resources/Viewer_cs.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Viewer_cs.properties 6 Nov 2002 14:30:16 - 1.1 +++ Viewer_cs.properties 7 Nov 2002 07:44:58 - 1.2 @@ -1,34 +1,34 @@ -# -# Copyright (C) The Apache Software Foundation. All rights reserved.# -# - # -# This software is published under the terms of the Apache Software License # -# version 1.1, a copy of which has been included with this distribution in # -# the LICENSE file. # -# -# -# AWT viewer's GUI resources. Czech bundle. -# -Menu.File=Soubor -Menu.Print=Tisk -Menu.Exit=Konec -Menu.View=Zobrazit
