DO NOT REPLY [Bug 17118] New: - XSLTInputHandler fails with InputSource and URL in constructor
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=17118.
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=17118
XSLTInputHandler fails with InputSource and URL in constructor
Summary: XSLTInputHandler fails with InputSource and URL in
constructor
Product: Fop
Version: 0.20.5
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I noticed while using an XSLTInputHandler, that is does not work for other
input sources than File:
String xmlURL = test.xml, xslURL = test.xsl;
XSLTInputHandler ih1 = new XSLTInputHandler(xmlURL,xmlURL);
XSLTInputHandler ih2 = new XSLTInputHandler(new InputSource(xmlURL),new
InputSource(xslURL));
XSLTInputHandler ih3 = new XSLTInputHandler(new File(xmlURL),new File(xslURL));
Driver d = new Driver();
d.render(ih1.getParser(),ih1.getInputSource()); // fails!
d.render(ih2.getParser(),ih2.getInputSource()); // fails!
d.render(ih3.getParser(),ih3.getInputSource()); // works!
The failures are NullPointerExceptions. I assume, that TraxInputHandler.java
(which is the delegation of XSLTInputHandler) is not fully compliant with other
sources than file. Here is a version of TraxInpuHandler that should work.
/*
* $Id: TraxInputHandler.java,v 1.1 2003/02/12 15:09:03 ilja 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.
*/
package org.apache.fop.apps;
// Imported TraX classes
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.Source;
import javax.xml.transform.stream.StreamSource;
import javax.xml.transform.sax.SAXResult;
import javax.xml.transform.sax.SAXSource;
import javax.xml.transform.sax.SAXTransformerFactory;
// Imported SAX classes
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
import org.xml.sax.XMLFilter;
// Imported java.io classes
import java.io.InputStream;
import java.io.IOException;
import java.io.File;
import org.apache.fop.apps.*;
/**
* XSLTInputHandler basically takes an xmlfile and transforms it with an
xsltfile
* and the resulting xsl:fo document is input for Fop.
*/
public class TraxInputHandler extends InputHandler {
private Transformer transformer;
private StreamSource xmlSource;
private StreamSource xsltSource;
public TraxInputHandler(File xmlfile, File xsltfile)
throws FOPException {
xmlSource = new StreamSource(xmlfile);
xsltSource = new StreamSource(xsltfile);
initTransformer();
}
public TraxInputHandler(String xmlURL, String xsltURL)
throws FOPException {
this.xmlSource = new StreamSource(xmlURL);
this.xsltSource = new StreamSource(xsltURL);
initTransformer();
}
public TraxInputHandler(InputSource xmlSource, InputSource xsltSource)
throws FOPException {
this.xmlSource = new StreamSource(xmlSource.getByteStream(),
xmlSource.getSystemId());
this.xsltSource = new StreamSource(xsltSource.getByteStream(),
xsltSource.getSystemId());
initTransformer();
}
private void initTransformer() throws FOPException {
try {
transformer = TransformerFactory.newInstance().newTransformer
(xsltSource);
}
catch( Exception ex) {
throw new FOPException(ex);
}
}
/**
* overwrites the method of the super class to return the xmlfile
* @deprecated
*/
public InputSource getInputSource() {
InputSource is = new InputSource();
is.setByteStream(xmlSource.getInputStream());
is.setSystemId(xmlSource.getSystemId());
return is;
}
/**
* overwrites this method of the super class and returns an XMLFilter
instead of a
* simple XMLReader which allows chaining of transformations
* @deprecated
*
*/
public XMLReader getParser() throws FOPException {
return this.getXMLFilter(xsltSource);
}
/**
* Creates from the transformer an instance of an XMLFilter which
* then can be used in a chain with the XMLReader passed to Driver. This way
* during the conversion of the xml file + xslt stylesheet the resulting
* data is fed into Fop. This should help to avoid memory problems
* @param xmlfile The xmlfile containing the text data
*
Re: FOP API proposal in FOP wiki
On 05.02.2003 10:32:11 Klaas_Bals wrote: Let me first quickly introduce myself. The compay I work for, Inventive Designers, has a product called Scriptura, which is tool to work with XSLT and XSL-FO. Scriptura consists of a WYSIWYG designer for XSL stylesheets, and an Engine which does the processing (transformations, PDF generation etc). It is written in Java. For more info, see http://www.inventivedesigners.com/products/scriptura.html We are using FOP right now, but a lot of customers are asking for suppor tfor other XSL-FO formatters, which we encourage. However, right now we have to make a module for each of these XSL-FO formatters to access them using their proper APIs. We see the need for a uniform (Java?) API to access all (Java?) XSL-FO formatters, which ideally would become a part of the JAXP (Java APIs for XML processing). My opnion is that the Avalonized API does not qualify for a uniform API, because of too much of the Avalon components would have to become a part of this uniform API in order for it to be complete. Do you guys see this Avalonized API as the one an only and best way to access FOP, or are you interested in having a uniform API as well? Do you see this uniform API sitting on top of the Avalonized API? That was my original idea, to build FOP on Avalon, provide an Avalon-based API (for advanced users and Cocoon) but have a standard easy-to-use API that's not Avalon-based. Unfortunately, the Wiki page currently doesn't reflect this. Have a look at the Morphos proposal in Jakarta Commons Sandbox. It's a general-purpose transformation API. This could be a good start for a uniform API. I must admit that I did not completely follow the discussion about the FOP API, altough I browsed the archives. I couldn't find the final conclusion on the decision to use the Avalon approach. That's probably the concept of lazy concensus. Granted, Avalon has crept into FOP over time. It has started with logging. But I'm pretty sure that if we voted for Avalon today the majority of the committers would vote +1. Avalon has a lot of benefits for us (which I'm sure you've already come accross in the mailing list archives) and the Cocoon people (our biggest customer) will love us for neatly integrating FOP with them, because the current FOP is a PITA in such an environment. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP API proposal in FOP wiki
I've just decided not to comment any detail point that has been discussed ATM because I'm currently uneasy with the current process of forming the new API. It's too much of a bottom-up approach IMO. I fear that we're losing ourselves in some details when not even the high-level stuff is decided. I want to take it top-down: 1. top-level requirements (done, or does anyone have any additions?) 2. decide what kinds of APIs we're going to build. Only an Avalon-based one as the current Wiki suggests? Or an Avalon-based API targeted at the advanced user and a easy-to-use non-Avalon API as I suggested half a year ago? Shall we use Morphos as our Easy-API? Just questions that I'd like to have resolved before diving into details. 3. work out a detailed list of topics that need to be addressed (for example: different output formats: OutputStream, SAX events, AWT Graphics2D calls etc.) 4. Build up the API again based on the findings in 3 with the simple and essential things first (no image and font resolvers and similar), maybe even coding that part already to see if it might work. We can always change later. Let's stick to the fact that FOP is just a transformer/converter/morpher from a high-level view. Input in, output out. That's what the API should primarily be about. Things like resolvers are different concerns and have to do with the environment/configuration. This is to be separated IMO. Flame me... If not, please share your thoughts on point 2 now. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: On 15.02.2003 18:05:31 Christian Geisert wrote: [..] sidenote While doing a quick search for other hyphenation optiones I've found a hyphenation dictionary which is based on the TeX hyphenation tables and licensed under GNU LGPL ... /sidenote Do you have a link? LGPL is not unproblematic as could be seen in recent http://whiteboard.openoffice.org/lingucomponent/download_dictionary.html?JServSessionIdservlets=v100ota723#hyphenation See README in hyph_de_DE.zip But I'm not proposing to use those patterns, I was just wondering if it's ok to re-license it under LGPL. discussions on community@. I would want clearance from higher up before we used and (a different topic) redistributed the hyphenation patterns. I can take this to the PMC and to licencing if necessary. +1 [..] Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. So remove everything excpet fi, pl and pt? - Find Apache-compatible hyphenation files. Would be the best solution. - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. Could be troublesome (for example the german pattern file mentions three authors) Any volunteers? - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) IIUC we don't have to change the way the pattern are read, the problem is the distribuition. For example it should be ok if we create a new SourceForge project with just the hyphenation patterns and license it under LPPL. Then people could download the jar, put it in the lib dir and everything should be fine. - Maybe adjust FOP so it is more flexible reading hyphenation files. - Add something to future release notes about hyphenation. Jeremias Maerki Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Ready for rc2 ?
Hi all, everything done for release candidate 2 ? (except removing hyphenation patterns) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 17.02.2003 16:16:55 Christian Geisert wrote: Jeremias Maerki wrote: On 15.02.2003 18:05:31 Christian Geisert wrote: [..] sidenote While doing a quick search for other hyphenation optiones I've found a hyphenation dictionary which is based on the TeX hyphenation tables and licensed under GNU LGPL ... /sidenote Do you have a link? LGPL is not unproblematic as could be seen in recent http://whiteboard.openoffice.org/lingucomponent/download_dictionary.html?JServSessionIdservlets=v100ota723#hyphenation See README in hyph_de_DE.zip But I'm not proposing to use those patterns, I was just wondering if it's ok to re-license it under LGPL. Interesting. discussions on community@. I would want clearance from higher up before we used and (a different topic) redistributed the hyphenation patterns. I can take this to the PMC and to licencing if necessary. +1 [..] Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. So remove everything excpet fi, pl and pt? Yep, can you do that or shall I? - Find Apache-compatible hyphenation files. Would be the best solution. - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. Could be troublesome (for example the german pattern file mentions three authors) Any volunteers? I can try. - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) IIUC we don't have to change the way the pattern are read, the problem is the distribuition. No. The patterns in FOP are currently in some XML format. The patterns found on the web are in an ASCII format. FOP needs to be adjusted so it can read the ASCII files directly, I think. For example it should be ok if we create a new SourceForge project with just the hyphenation patterns and license it under LPPL. Then people could download the jar, put it in the lib dir and everything should be fine. If the patterns from OpenOffice work with our hyphenation system then we just need to make sure we can read them and point our users to that location. - Maybe adjust FOP so it is more flexible reading hyphenation files. - Add something to future release notes about hyphenation. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
* Jeremias Maerki; [EMAIL PROTECTED] on 14 Feb, 2003 wrote: tr.xml Can't find original file. No licence. Check with author. Well, since I sent out the Turkish hyphenation file I should know where it comes right. The trhyphen.tex is installed from the SuSE 8.1 distro toganm@earth:~/hangar rpm -qf /usr/share/texmf/tex/generic/hyphen/trhyph.tex tetex-beta.20020207-254 the trhyph.tex file has the following header % A mechanically generated Turkish Hyphenation table for TeX, % using the University of Washington diacritical coding % developed by P. A. MacKay for the Ottoman Texts Project. % Slightly modified by H. Turgut Uyar. Turgut Uyar has the following addres based on google search [EMAIL PROTECTED] Would you like to contact him directly or do you want me to do so ? Although I think you can explain the needs and requirements better than I can -- Togan Muftuoglu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
I can do that. Thanks for the info. On 17.02.2003 16:47:17 Togan Muftuoglu wrote: * Jeremias Maerki; [EMAIL PROTECTED] on 14 Feb, 2003 wrote: tr.xml Can't find original file. No licence. Check with author. Well, since I sent out the Turkish hyphenation file I should know where it comes right. The trhyphen.tex is installed from the SuSE 8.1 distro toganm@earth:~/hangar rpm -qf /usr/share/texmf/tex/generic/hyphen/trhyph.tex tetex-beta.20020207-254 the trhyph.tex file has the following header % A mechanically generated Turkish Hyphenation table for TeX, % using the University of Washington diacritical coding % developed by P. A. MacKay for the Ottoman Texts Project. % Slightly modified by H. Turgut Uyar. Turgut Uyar has the following addres based on google search [EMAIL PROTECTED] Would you like to contact him directly or do you want me to do so ? Although I think you can explain the needs and requirements better than I can Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Ready for rc2 ?
Yep, from my side. On 17.02.2003 16:19:23 Christian Geisert wrote: everything done for release candidate 2 ? (except removing hyphenation patterns) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: [..] So remove everything excpet fi, pl and pt? Yep, can you do that or shall I? I'll do it. [..] IIUC we don't have to change the way the pattern are read, the problem is the distribuition. No. The patterns in FOP are currently in some XML format. The patterns found on the web are in an ASCII format. FOP needs to be adjusted so it can read the ASCII files directly, I think. I was thinking about distributing our .hyp files via SourceForge under LPPL. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 17.02.2003 17:11:42 Christian Geisert wrote: Jeremias Maerki wrote: [..] So remove everything excpet fi, pl and pt? Yep, can you do that or shall I? I'll do it. Thanks! [..] IIUC we don't have to change the way the pattern are read, the problem is the distribuition. No. The patterns in FOP are currently in some XML format. The patterns found on the web are in an ASCII format. FOP needs to be adjusted so it can read the ASCII files directly, I think. I was thinking about distributing our .hyp files via SourceForge under LPPL. That seems awkward. It would be much easier to just point our users to OpenOffice or some FTP directory. Is it really necessary from a performance point of view to create the .hyp files? Does anyone know? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence issues in hyphenation patterns
Jeremias Maerki wrote: Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. - Find Apache-compatible hyphenation files. I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. This would be unnecessary if we start with the right base build from there. - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) I have no objection to this, but the conversion does not look very complicated, and if we distribute our own, then there is no need for it. Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Embedding examples (or tutorial) and new directory structure
http://xml.apache.org/fop/embedding.html lists 6 different examples of embedding fop. Where do I find these example files? I can't find them in any of the distributions. Dave - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 3:15 PM Subject: Embedding examples (or tutorial) and new directory structure Hi there I've committed my first set set of embedding examples to the branch. I decided not to call it a tutorial, because that's not what it is. The intentions have stayed the same since the annoucement, though. I intend to add the documentation for the above in the next couple of days. Is that ok, if I just add that to the bottom of embedding.html? It won't be much anyway. I placed the new files in the newly created examples directory in accordance to what we discussed around december 1st. I will relocate the contrib stuff and the fo examples to this directory, too. I decided not to hack away at the server side CVS directories. Too much headache included. I'll just copy, commit, delete. I'd like to get rid of the docs directory in the end. I think there's still the -1 from Oleg concerning the src/foschema. How do we resolve that? We've got: 1. src/foschema (my proposal, +1 from Keiron and Jörg) 2. src/documentation/test/foschema (Oleg's preferred location. Did I get you right on this?) I would also like to get src/org to src/java/org. I think it's ok to lose history on the contrib and docs stuff when relocating. But that's not so easy with the Java sources. I'm not going to do CVS surgery. Do we have a volunteer? Pleeease? :-) 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: Embedding examples (or tutorial) and new directory structure
They are currently only available through CVS. If you can wait until Tuesday or Wednesday there will be a 0.20.5rc2 release that will contain the examples. You can also find them here: http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/Attic/ Sorry for the inconvenience. On 17.02.2003 20:48:04 David Frankson wrote: http://xml.apache.org/fop/embedding.html lists 6 different examples of embedding fop. Where do I find these example files? I can't find them in any of the distributions. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP API proposal in FOP wiki
Jeremias Maerki wrote: That was my original idea, to build FOP on Avalon, provide an Avalon-based API (for advanced users and Cocoon) but have a standard easy-to-use API that's not Avalon-based. Unfortunately, the Wiki page currently doesn't reflect this. No problem here: edit the proposal to reflect your views. It's a wiki! Avalon has a lot of benefits for us This is exactly the problem with Avalon: it benefits the developers. But does it benefit the *users* in a tangible manner (other than getting the software earlier)? Exposing an Avalon-only API *will* get us flames. Users don't want to step up another learning curve. Particularly if the accumulated knowledge can't be reused elsewhere. How many public projects are there beside Cocoon which draw heavily from Avalon? I get 5 in the first 100 matches of a Google search (one of them, ironically, on savannah). BTW type avalon and framework into Google for a surprise. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP API proposal in FOP wiki
On 17.02.2003 21:08:20 J.Pietschmann wrote: Jeremias Maerki wrote: That was my original idea, to build FOP on Avalon, provide an Avalon-based API (for advanced users and Cocoon) but have a standard easy-to-use API that's not Avalon-based. Unfortunately, the Wiki page currently doesn't reflect this. No problem here: edit the proposal to reflect your views. It's a wiki! I'll get to that. I just don't want to stand on your toes. You've got your view, I've got mine. I want to get a solution that all of us are happy with. Avalon has a lot of benefits for us This is exactly the problem with Avalon: it benefits the developers. But does it benefit the *users* in a tangible manner (other than getting the software earlier)? Exposing an Avalon-only API *will* get us flames. I know. That's exactly the reason for the Easy API. Users don't want to step up another learning curve. Particularly if the accumulated knowledge can't be reused elsewhere. How many public projects are there beside Cocoon which draw heavily from Avalon? I get 5 in the first 100 matches of a Google search (one of them, ironically, on savannah). Yes, yes, heard that argument many times now. BTW type avalon and framework into Google for a surprise. Already knew that one. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Christian Geisert wrote: Jeremias Maerki wrote: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. So remove everything excpet fi, pl and pt? Ouch. I don't think we can distribute FOP without english hyphenation. I just had another look at the LPPL and the other files. The LPPL file I examined seems to be harmless. The license says we can distribute the hyphenation XML file as derived from the original TeX hyphenation file as long as there is a pointer/URL to the original The Program. It's not quite clear to me what The Program is in case of the hyphenation file, but it doesn't seem to include much more than the hyphenation file itself, in this case, as there isn't much more in the directory. The only other condition is that the file must have another name (no problem). I think we are safe for the source distribution including LPPL hyphenation files. A binary distribution is another matter because of the compiled *.hyph files, which are obviously derived. But again it should be safe if we include a prominent remark in a README or LICENSE that the distribution contains such and such stuff defrived from foobar files, and provide URLs to the original TeX files. Of course, getting the XML files under the Apache license would save us this hassle. As for the other files, I think es.xml is safe too. While there's mentioned the source was taken from Lout, it does not put it automatically under GPL, and there is a license further down the file which reads roughly like the artistic license. The really problematic files are cs.xml, sk.xml and no.xml, which are explicit GPL. I don't think there is harm for the ASF if these files are distributed as-is with a source distribution, but compiling them into a *.hyphs into a jar would make the entire binary distribution GPL! Mind numbing... And, well, I hope our PetroBras friend changed enough of the pt.xml to claim copyright, as he assigned it summarily to the ASF... nice, but a real legal burden! I checked it in, but now I think I should have asked for a paper first. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Ready for rc2 ?
Christian Geisert wrote: everything done for release candidate 2 ? I think so. (except removing hyphenation patterns) Uh! Oh! :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Can't bind page number into a variable
Hi, I would like to put specific attributes on odd or even pages, so I began by looking for a way to check the context pages but I did'nt find anything. So I wanted to bind the fo:page-number / into a variable in order to make some test on it when I want to add specific parameters to my tags. xsl:variable name=page_numberfo:page-number //xsl:variable xsl:if test=($page_number mod 2)=1 xsl:attribute name=text-alignstart/xsl:attribute /xsl:if xsl:if test=($page_number mod 2)=0 xsl:attribute name=text-alignend/xsl:attribute /xsl:if But it looks like being impossible to bind the fo:page-number / into a variable or param (I tried to write my variable in a block but it looks like being setted to by the fo:page-number tag). Is here a reason for my variable to be null ? And is there a way to detect the context where I am currently in while writing in a non-static content ? I also tried to make a template with a page_number param but it doesn't work either... Here are some examples of my pdf outputs : http://www.tatouage.fr/temp/ap_skin_example.pdf (here I want to align my titles at the start or the end of the block depending of the odd or even condition, I am in a non-static context) http://www.tatouage.fr/temp/cd_skin_example.pdf (It's the same with this skin but it will be easier for me because every objects have statical position on the page = I have one odd and one even page for each XML FICHE tag, so I'll be able to manage the whole page breaking in XSLT) Sorry for disturbing you developpers with my little problem, but it makes me so nervous ... :/ Thanks for your work on this API. Simon OUALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Plan for HEAD
Keiron Liddle wrote: What standard are you looking for in a dev release. All commonly used FO features + any goodies that drop in for free. The feature set of 0.20.1 seems to be mostly ok (i.e. keeps and markers mostly broken, large parts of table formatting botched, misplaced link areas, all kind of trouble with footnotes etc.) For the renderers, I'd take only PS, PCL, XML and AWT as important, leaving SVG, TIFF, MIF and text for later. Do we include the new api in the release. I think so. Actually, I suppose we release a 0.21.0 from the maintenance branch with the new API tacked on once it stabilizes (and the old still there but deprecated), so people can get used to it. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP API proposal in FOP wiki
Jeremias Maerki wrote: I just don't want to stand on your toes. If I were afraid of someone stepping on my toes, I'd either shut up or commit the stuff right to CVS and damn the flak! The wiki is a whiteboard for collecting ideas. This includes wiping stuff which did not stand the test of time. After all, you can easily restore it if necessary. The mailing list is for dialogues and argumentation. I admit it takes some time to get used to this. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Markers in areas
Joerg, you can freely get rid of that stuff. I originally introduced it when I had more faith in the spec, and thought that the authors knew what they were talking about when it came to to their math. Specifically, the lineage pairs is an abstract concept that I can see no implementation use for. In fact, I can't see any theoretical use for the idea either. Arved -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: February 16, 2003 8:14 PM To: [EMAIL PROTECTED] Subject: Markers in areas Hi, does somebody need the markers attached to an area? I just canned them, as well as another array atteched to areas (lineage pairs). Markers were only used in the XML renderer. They ought to have uses to implement retrieve-positions first-include-carryover and last-ending-within-page, but they didn't get used for this. Objections? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
font problem in fop generated pcl file
Hi guys. I have an interesting problem that I hope you can help with. I am trying to get the font Garamond printed on my pcl output. When I use pdf as the output the font is on the pdf document. But when I use -pcl as the output, there is no Garamond font there. The following are excerps from the userconfig file, the command line argument I use to generate the pcl, and output printlines from fop. !-- userconfig -- fonts font metrics-file=file://c:/java/investec/conf/gara.xml kerning=yes embed-file=file:///c:/windows/fonts/GARA.TTF font-triplet name=Garamond style=normal weight=normal/ /font font metrics-file=file://c:/java/investec/conf/garab.xml kerning=yes embed-file=file:///c:/windows/fonts/GARABD.TTF font-triplet name=Garamond style=normal weight=bold/ /font /fonts !-- command line arguments -- fop -c c:\java\investec\conf\userconfig.xml -xml c:\1.xml -xsl c:\1.xsl -pcl c:\1.pcl !-- fop output -- C:\fop\fop-0.20.4java -cp build\fop.jar;lib\batik.jar;lib\xalan-2.3.1.jar;lib\xercesImpl-2.0.1.jar;lib \xml-apis.jar;lib \avalon-framework-cvs-20020315.jar;lib\logkit-1.0.jar;lib\jimi-1.0.jar org.apache.fop.apps.Fop -c c:\java\investec\conf\ userconfig.xml -xml c:\1.xml -xsl c:\1.xsl -pcl c:\1.pcl [INFO] FOP @version@ [INFO] building formatting object tree [INFO] rendering areas to PCL [INFO] [1] [INFO] [2] [INFO] [3] [INFO] [4] [INFO] Parsing of document complete, stopping renderer [INFO] writing out PCL When I output to -pdf, The fop printlines are exactly the same. The only difference is that the garamond font is on the pdf. Please help. Thanks Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: font problem in fop generated pcl file
Darryl Nortje wrote: I am trying to get the font Garamond printed on my pcl output. When I use pdf as the output the font is on the pdf document. But when I use -pcl as the output, there is no Garamond font there. The following are excerps from the userconfig file, the command line argument I use to generate the pcl, and output printlines from fop. This is a question for fop-user, but: you embed a TrueType font into you PDF file. The PCL (and PostScript as well) output of FOP do not implement font embedding, TrueType format or not. So, for this to work, you'd have to download the Garamond font to your PCL printer prior to printing the PCL file produced by FOP. How you do this and in which format (I don't really know PCL 6, but in old PCL, you cannot use TrueType fonts) is up to you (and your actual printer), unfortunately. You don't get a different log output, because FOP cannot look into your printer and therefore cannot see whether the Garamond font is there. So it assumes everything is ok and doesn't log an error. Hope this helps, Arnd -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
J.Pietschmann schrieb: [..] Ouch. I don't think we can distribute FOP without english hyphenation. Sure we *can* ;-) But if it's a good thing ... I just had another look at the LPPL and the other files. The LPPL file I examined seems to be harmless. The license says we can distribute the hyphenation XML file as derived from the original TeX hyphenation file as long as there is a pointer/URL to the original The Program. It's not quite clear to me what The Program is in case of the hyphenation file, but it doesn't seem to include much more than the hyphenation file itself, in this case, as there isn't much more in the directory. The only other condition is that the file must have another name (no problem). And IMHO (and IANAL etc.) this is the crux as the Apache Software License does not forbid renamming the files. Yes, that's hairsplitting and comletly against common sense but remember we're talking about legal issues her. I think we are safe for the source distribution including LPPL hyphenation files. A binary distribution is another matter because of the compiled *.hyph files, which are obviously derived. But again it should Hu? Above you said the XML files are also derived. What's the difference between source and binary distribution? [..] As for the other files, I think es.xml is safe too. While there's mentioned the source was taken from Lout, it does not put it automatically under GPL, and there is a license further down the file which reads roughly like the artistic license. Ok. [..] And, well, I hope our PetroBras friend changed enough of the pt.xml to claim copyright, as he assigned it summarily to the ASF... nice, but a real legal burden! I checked it in, but now I think I should have asked for a paper first. So I'll remove it for RC2 and it will hopefully be resolved till the final release. I had another look at the files and the following seem to be ok too: en_GB.xml - may be freely distributed. it.xml - Use of the original work granted by the author Christian P.S. Yes I'm rushing a bit but I'll be on holiday from tomorrow till sunday and I want to make the RC before leaving. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/hyph cs.xml da.xml de.xml de_DR.xml el.xml en.xml en_US.xml fr.xml nl.xml no.xml pt.xml ru.xml sk.xml tr.xml
chrisg 2003/02/17 20:39:12 Removed: src/hyph Tag: fop-0_20_2-maintain cs.xml da.xml de.xml de_DR.xml el.xml en.xml en_US.xml fr.xml nl.xml no.xml pt.xml ru.xml sk.xml tr.xml Log: removed hyphenation patterns with unclear/problematic license - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs relnotes.xml
chrisg 2003/02/17 20:41:47 Modified:src/documentation/content/xdocs relnotes.xml Log: added info about removed hyphenation pattern Revision ChangesPath 1.5 +6 -1 xml-fop/src/documentation/content/xdocs/relnotes.xml Index: relnotes.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/relnotes.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- relnotes.xml 18 Jan 2003 18:04:58 - 1.4 +++ relnotes.xml 18 Feb 2003 04:41:47 - 1.5 @@ -13,8 +13,13 @@ pThis is the last planed release in the 0.20.x series (aka maintenance branch)./p pImportant changes since the last release (0.20.4):/p ul +liSome hyphenation patterns (cs, da, de, de_DR, el, en, en_US, fr, nl, +no, pt, ru, sk, tr) have been removed due to licensing reasons. +We hope to resolve this issue until the final release. +(English hyphenation is still available as en_GB) +/li liDocumentation is done with link href=http://xml.apache.org/forrest/; -Forrest/link. You need to install Forrest if you want build the docs +Forrest/link (version 0.3). You need to install Forrest if you want build the docs yourself. (See link href=http://xml.apache.org/forrest/your-project.html;Using Forrest/link) /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
