Re: FOP Extension to handle Wiki Syntax
On 14 Jun 2011, at 16:46, Glenn Adams wrote:
> You know, given the time spent answering questions about XSL and the XML+XSL
> -> XSL-FO front-end ("convenience mechanism") in FOP, I sometimes wonder if
> it would be better to rip out that function. Perhaps then folks would
> understand better that FOP is fundamentally an XSL-FO -> output format
> processor.
FOP did start that way, if I recall correctly. There was a time when including
the possibility to feed XML+XSLT as input was considered a big win. I actually
think going back makes little sense, especially given that the usage pattern
for embedding is basic JAXP. Even if you feed FOP plain FO, an identity
transformation is used nowadays, also when invoking via the CLI.
Way back when, using the CLI with plain FO actually did not use the XSLT
processor at all, just the XML parser.
Another point would be that XSL-FO itself defines nearly all its examples in
terms of XSLT that transforms semantic XML to FO... *shrug*
It is easy to see how newcomers get confused. Ultimately, we could just respond
with a link to the website, where it is darn' well explained what the
recommended practice is in case of problems (i.e. submit FO, not XSLT; if the
problem is XSLT, go to Mulberry etc.).
Nonetheless, I'll probably never get tired of pointing it out to people --even
if they do seem to lack the most basic web browsing skills sometimes... ;-)
On 14 Jun 2011, at 12:09, kalgon wrote:
>
> What I would like to know is how I can build a tree of FONodes (blocks,
> text, table...) programmatically while parsing my wiki text and feed that
> tree to the FOP engine. I've been looking at ElementMapping, XMLHandler and
> the likes but I can't get a good grip at how those are working.
>
> If somebody could point me to a good and complete tutorial on FOP extensions
> or send me a nice example of how to do it, that would help me a lot!
In this particular case, I would agree with the assessment that a FO extension
would not be the most efficient/productive choice. While I can explain how to
insert a new Block into the stream, I still would not encourage it. The quick
and dirty approach, with probably the highest probability of success, would be
to just send the appropriate SAX events back to the FOTreeBuilder.
So, your code would have to be full of:
Attributes myAttrs = new AttributesImpl();
myAttrs.addAttribute("", "font-weight", "font-weight", "CDATA", "bold");
...
builder.startElement(FO_URI, "block", "fo:block", myAttrs);
...
builder.endElement(FO_URI, "block", "fo:block", myAttrs);
I am not entirely certain it will always work, but I don't immediately see
another way that would cheaply allow you to get potential property inheritance
right, or have your content behave properly if it is contained in a fo:marker...
This shows that FOP's API simply isn't designed with that in mind. Internally,
it is meant to parse formatting objects from XML source. FO extensions only
allow you to go so far. The extension mechanism is mainly meant to allow you to
handle custom, foreign XML (= non-FO, e.g. to plug in a handler for your custom
child object of fo:instream-foreign object; prime examples SVG, MathML,
Barcode4J...). Translating flat text markup into FO (or more generally: XML),
not so much.
Don't get me wrong. I like the whole idea of being able to translate MediaWiki
fragments directly into FO. Seems a very useful thing to have, however...
Given the power of XSLT/XPath 2.0 to handle regex processing of unparsed text
and consistent generation of valid XML(FO) nodes (even when the nesting levels
get too difficult to follow for the human mind and its programming logic), this
seems like THE weapon of choice for such a job. With a bit of imagination, one
can easily keep this generic enough to work for a multitude of source XMLs.
Just write a small stylesheet library to translate arbitrary MediaWiki markup
into the corresponding FO syntax, and plug it into the main stylesheet.
Sequences and xsl:functions are truly powerful stuff!
If you feel generous, make it publicly available for everyone to try
out/correct/extend... I'm quite sure it will get all the attention it deserves.
We would gladly link to it from our website (or accept a contribution on the
Wiki ;-))
Regards
Andreas
---
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Problems with FOP and image
On 06/14/2011 11:06 AM, Oscar.Flores wrote:
Yeah i do the class is in jai-imageio-1.1-sources.jar, the enviroment is just
Having the file in the "...sources.jar" won't do the runtime world much
good. You need the jar of .class files for jai-imageio, not .java files
windows xp, and the bufferedImage will be the path of the image??
No, the bufferedImage is an in-memory instance of BufferedImage holding
the bits of the image. In the case that you have to read it from one
place and write it to another.
Rob Sargent-4 wrote:
Did you go through all your jars looking for 'CLibJPEGImageReaderSpi'.
My greatest suspicion is that you don't have all your jars lined up.
Which jar(s) do you think supplies these?
What is your environment: just windows or do you have any tools like
cygwin?
The "jpegImageFile" would be the filename in your xsl the
external-resource. If you're just using a file that is already in place
you don't have to re-write it.
On 06/14/2011 08:29 AM, Oscar.Flores wrote:
No i dont, and that weird jejeje netbeans seems to do that for me, so the
calls like ImageIO.write(BufferedImage, "JPEG", jpegImageFile)? do i have
to
do it in every image that i put in the pdf?? and the image is gererate
directly in the pdf??how can i do it??
Rob Sargent-4 wrote:
Some jar to which netbeans has access has those classes. Look in the
output of jar tvf and see if any of those has the
named classes. If you find a jar with those classes make sure it's part
of your classpath for you app.
Are you making any calls like ImageIO.write(BufferedImage, "JPEG",
jpegImageFile)?
On 06/13/2011 05:31 PM, Oscar.Flores wrote:
ok i made a test and tell me that the class is missign but maybe what
you
say
its rigth and it register the handler
so i gonna register the services so i do this
public static void main(String[] args) throws Exception {
DOMConfigurator.configure("D:/Mis
documentos/NetBeansProjects/Factura/src/factura/log4j.xml");
logger.info("Entering application.");
IIORegistry.getDefaultInstance().registerServiceProvider(new
CLibJPEGImageReaderSpi());
IIORegistry.getDefaultInstance().registerServiceProvider(new
CLibJPEGImageWriterSpi());
also after register my services it telling me that the class
CLibJPEGImageReaderSpi() and CLibJPEGImageWriterSpi() is missing but
only
in
command
after register mi service, something more has to be done??
Rob Sargent-4 wrote:
I'm not sure I'm following correctly: does removing the xmlgraphics
jar
cause netbeans to behave the same as the command-line run of you app?
If
so, I suspect netbeans is registering services for you. Your own code
will have to make a call to one of the
IIORegistry.registerServiceProvider() methods.
On 06/13/2011 05:02 PM, Oscar.Flores wrote:
Ok i get it, actually the ImageIO library i added because i read
in
the
xmlgrapics that if something like the message
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no
suitable loader/converter combination available)appear i have to add
the
jar
file to the classpath but that all it say no configuration or
anything,
then
i delete the imagenIO libs and still i have the same output in
netbeans
so
xmlgrapics seem to have the problem in the plugins or i have to
configure
something
Rob Sargent-4 wrote:
Then it seems to me netbeans (if it's producing good output ==
assumptionA) is still using something that the command-line isn't.
And given assumptionA, you're java code is correct in terms of FOP
and
your configuration isn't for ImageIO. Show your ImageIO related
code
and are you sure it's in your app. Use the logger to show a message
when you add your loader. Or list all ImageIO services:
IIORegistry.getServiceProviders()
On 06/13/2011 03:01 PM, Oscar.Flores wrote:
ok well i put the xml in scr of my proyect i see that i still have
the
same
issues of the image render of any image i dont now if the xml its
in
place i
put the code down to see if something its missing
15:45:07,827 ERROR [render] Error while processing image:
c:\cfd\nombregp.bmp (i
mage/bmp)
org.apache.xmlgraphics.image.loader.ImageException: Cannot load
image
(no
suitab
le loader/converter combination available) for c:\cfd\nombregp.bmp
(image/bmp)
at
org.apache.xmlgraphics.image.loader.ImageManager.getImage(ImageManage
import mx.bigdata.sat.cfd.schema.Comprobante;
import mx.bigdata.sat.cfd.CFDv2;
import mx.bigdata.sat.security.KeyLoader;
import org.jdom.*;
import org.jdom.input.SAXBuilder;
import org.jdom.output.XMLOutputter;
import org.jdom.output.Format;
import org.jdom.transform.JDOMSource;
//Java
import java.io.File;
import java.io.OutputStream;
//JAXP
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.Source;
import javax.xml.transform.Result;
import javax.xml.transform.stream.StreamSource;
import javax.xml.transform.sax.SAXResult;
//F
Re: Text Overflows into adjacent cell
Andreas L. Delmelle telenet.be> writes: > > On 13 Jun 2011, at 22:53, Chetan Shirol wrote: > > Hi Chetan > > > I am upgrading fop from .25 to .95 and facing the below issue. Please help. > > > > > > Case 2: > > Long text with No white space like > > eg: ReallyReallyLongTextNoWhiteSpace > > > > then the text flows- overlaps the next column. > > FOP implements Unicode line-breaking rules, and those do not allow to break the sample text fragment anywhere. > The usually suggested workaround is to alter the stylesheet, so that ZWSPs (U+200B) are inserted that give > FOP a chance to break. > > So, you should get the equivalent of: > Really... > > That will effectively lead to a 'wrapping' effect, i.e. FOP will place as many characters as possible in a > line, and break at the next ZWSP. > > This is currently the only around this, AFAIK. > > Hope this helps! > > Regards > > Andreas > --- > Hi Andreas, Thanks for your mail. But in our case the text I that I will be using is dynamically generated. Please let me know if there is any other way/option to fix this. With earlier .25 fop jar it worked well to keep the text inside the cell. Regards Chetan V S - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Text fill color in external SVG is not preserved
On 14 Jun 2011, at 02:10, Matthias Reischenbacher wrote: >> >> I use Fop - nightly build on Win7/64 bit + Java 6. >> >> All the a, b, c, d labels should be red (first two are red, the rest is >> black) >> All the Text (1, 2, 3) should be white (first two are white, the third is >> black) > > I believe this issue is caused by the commit of rev 1095887. I've already > reported to the commiter (Jeremias) which, I think, is working on a fix. But > you might want to create a bugzilla entry anyway as Andreas suggested. Just in case anyone missed it: Jeremias committed the fix to FOP trunk today, so the next nightly build should work. I have verified locally that the supplied sample now renders as expected. Thanks, Jeremias! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Problems with FOP and image
Yeah i do the class is in jai-imageio-1.1-sources.jar, the enviroment is just
windows xp, and the bufferedImage will be the path of the image??
Rob Sargent-4 wrote:
>
> Did you go through all your jars looking for 'CLibJPEGImageReaderSpi'.
> My greatest suspicion is that you don't have all your jars lined up.
> Which jar(s) do you think supplies these?
>
> What is your environment: just windows or do you have any tools like
> cygwin?
>
> The "jpegImageFile" would be the filename in your xsl the
> external-resource. If you're just using a file that is already in place
> you don't have to re-write it.
>
>
>
> On 06/14/2011 08:29 AM, Oscar.Flores wrote:
>> No i dont, and that weird jejeje netbeans seems to do that for me, so the
>> calls like ImageIO.write(BufferedImage, "JPEG", jpegImageFile)? do i have
>> to
>> do it in every image that i put in the pdf?? and the image is gererate
>> directly in the pdf??how can i do it??
>>
>> Rob Sargent-4 wrote:
>>> Some jar to which netbeans has access has those classes. Look in the
>>> output of jar tvf and see if any of those has the
>>> named classes. If you find a jar with those classes make sure it's part
>>> of your classpath for you app.
>>>
>>> Are you making any calls like ImageIO.write(BufferedImage, "JPEG",
>>> jpegImageFile)?
>>>
>>> On 06/13/2011 05:31 PM, Oscar.Flores wrote:
ok i made a test and tell me that the class is missign but maybe what
you
say
its rigth and it register the handler
so i gonna register the services so i do this
public static void main(String[] args) throws Exception {
DOMConfigurator.configure("D:/Mis
documentos/NetBeansProjects/Factura/src/factura/log4j.xml");
logger.info("Entering application.");
IIORegistry.getDefaultInstance().registerServiceProvider(new
CLibJPEGImageReaderSpi());
IIORegistry.getDefaultInstance().registerServiceProvider(new
CLibJPEGImageWriterSpi());
also after register my services it telling me that the class
CLibJPEGImageReaderSpi() and CLibJPEGImageWriterSpi() is missing but
only
in
command
after register mi service, something more has to be done??
Rob Sargent-4 wrote:
> I'm not sure I'm following correctly: does removing the xmlgraphics
> jar
> cause netbeans to behave the same as the command-line run of you app?
> If
> so, I suspect netbeans is registering services for you. Your own code
> will have to make a call to one of the
> IIORegistry.registerServiceProvider() methods.
>
> On 06/13/2011 05:02 PM, Oscar.Flores wrote:
>> Ok i get it, actually the ImageIO library i added because i read
>> in
>> the
>> xmlgrapics that if something like the message
>> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
>> (no
>> suitable loader/converter combination available)appear i have to add
>> the
>> jar
>> file to the classpath but that all it say no configuration or
>> anything,
>> then
>> i delete the imagenIO libs and still i have the same output in
>> netbeans
>> so
>> xmlgrapics seem to have the problem in the plugins or i have to
>> configure
>> something
>>
>> Rob Sargent-4 wrote:
>>> Then it seems to me netbeans (if it's producing good output ==
>>> assumptionA) is still using something that the command-line isn't.
>>>
>>> And given assumptionA, you're java code is correct in terms of FOP
>>> and
>>> your configuration isn't for ImageIO. Show your ImageIO related
>>> code
>>> and are you sure it's in your app. Use the logger to show a message
>>> when you add your loader. Or list all ImageIO services:
>>> IIORegistry.getServiceProviders()
>>>
>>> On 06/13/2011 03:01 PM, Oscar.Flores wrote:
ok well i put the xml in scr of my proyect i see that i still have
the
same
issues of the image render of any image i dont now if the xml its
in
place i
put the code down to see if something its missing
15:45:07,827 ERROR [render] Error while processing image:
c:\cfd\nombregp.bmp (i
mage/bmp)
org.apache.xmlgraphics.image.loader.ImageException: Cannot load
image
(no
suitab
le loader/converter combination available) for c:\cfd\nombregp.bmp
(image/bmp)
at
org.apache.xmlgraphics.image.loader.ImageManager.getImage(ImageManage
import mx.bigdata.sat.cfd.schema.Comprobante;
import mx.bigdata.sat.cfd.CFDv2;
import mx.bigdata.sat.security.KeyLoader;
import org.jdom.*;
import org.jdom.input.SAXBuilder;
import org.jdom.output.XMLOutputter;
import org.jdom.output.Format;
Re: FOP Extension to handle Wiki Syntax
Of course, an extension can do anything you want. But you have to define it and write the Java that implements it. Again, I question the basis of your question. The XSL-FO tree starts out as an XML document, having the root node of fo:root, and adhering to the XSL-FO specification. You should write an external tool that takes whatever format you like (wiki) and translates it to XSL-FO, then feed that to FOP. Forget about the XML/XSLT to XSL-FO front-end preprocessor in FOP. If you want to "define an extension" to do what you want in FOP, you are basically asking for an extension to the front end XML/XSLT processing convenience mechanism in FOP. However, this is based on off-the-shelf XML and XSLT tools (xerces, xalan). So basically, you are asking for an extension to one of these latter tools, not an extension for XSL-FO. G. On Tue, Jun 14, 2011 at 9:54 AM, kalgon wrote: > > You're right, I shouldn't have been talking so much about the context of > what > I want to achieve, the only question that matters to me is: "is it possible > for an extension to programmatically add standard FO nodes to the main FO > tree, if yes how?". That is all I want to know and until now, nobody has > been able to answer that question. I see that FOP does have a lot of > extension points but very few documentation about their usage, and I don't > mind it this is not the correct way of doing things. I never started the > debate about that, I just wanted a simple plain answer to my question. > > Regards, > > Kalgon > > > Christopher R. Maden wrote: > > > > On 06/14/2011 11:23 AM, kalgon wrote: > >> I understand but if we want to be strict, XSLT only transform from XML > to > >> another format (often XML but also Text). In my case wiki syntax is not > >> XML > >> so we could say it shouldn't be transformed through XSLT. > > > > Text nodes are part of XML... XSLT can handle processing the contents of > > those text nodes. > > > > However, it’s not always the best tool for doing that. I would probably > > write something in your language-of-choice that takes in an XML tree and > > writes it out identically, except for upgrading the free-text markup. > > There are converters out there to do it... the Freebase BFG project used > > one written by one of the original Wikipedia markup designers... see > > https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske>. > > > > This has gotten off-topic for FOP. If you decide to do this in XSLT, > > see http://www.mulberrytech.com/xsl/xsl-list/ >. Otherwise, see > > the discussion fora for whatever other programming language you’re using. > > > > ~Chris > > -- > > Chris Maden, text nerd http://crism.maden.org/ > > > “Before I built a wall I’d ask to know / What I was walling in or > > out, / And to whom I was like to give offence.” — RF, Mending Wall > > GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 > > > > - > > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > > > > > > -- > View this message in context: > http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31844121.html > Sent from the FOP - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > >
Re: FOP Extension to handle Wiki Syntax
We have success "editing" the fo programmatically, parsing out some special strings our application embeds in the xml/text nodes. Not something we're necessarily proud of, but it works perfectly well. On 06/14/2011 09:54 AM, kalgon wrote: You're right, I shouldn't have been talking so much about the context of what I want to achieve, the only question that matters to me is: "is it possible for an extension to programmatically add standard FO nodes to the main FO tree, if yes how?". That is all I want to know and until now, nobody has been able to answer that question. I see that FOP does have a lot of extension points but very few documentation about their usage, and I don't mind it this is not the correct way of doing things. I never started the debate about that, I just wanted a simple plain answer to my question. Regards, Kalgon Christopher R. Maden wrote: On 06/14/2011 11:23 AM, kalgon wrote: I understand but if we want to be strict, XSLT only transform from XML to another format (often XML but also Text). In my case wiki syntax is not XML so we could say it shouldn't be transformed through XSLT. Text nodes are part of XML... XSLT can handle processing the contents of those text nodes. However, it’s not always the best tool for doing that. I would probably write something in your language-of-choice that takes in an XML tree and writes it out identically, except for upgrading the free-text markup. There are converters out there to do it... the Freebase BFG project used one written by one of the original Wikipedia markup designers... see https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske>. This has gotten off-topic for FOP. If you decide to do this in XSLT, seehttp://www.mulberrytech.com/xsl/xsl-list/>. Otherwise, see the discussion fora for whatever other programming language you’re using. ~Chris -- Chris Maden, text nerdhttp://crism.maden.org/> “Before I built a wall I’d ask to know / What I was walling in or out, / And to whom I was like to give offence.” — RF, Mending Wall GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Problems with FOP and image
Did you go through all your jars looking for 'CLibJPEGImageReaderSpi'.
My greatest suspicion is that you don't have all your jars lined up.
Which jar(s) do you think supplies these?
What is your environment: just windows or do you have any tools like cygwin?
The "jpegImageFile" would be the filename in your xsl the
external-resource. If you're just using a file that is already in place
you don't have to re-write it.
On 06/14/2011 08:29 AM, Oscar.Flores wrote:
No i dont, and that weird jejeje netbeans seems to do that for me, so the
calls like ImageIO.write(BufferedImage, "JPEG", jpegImageFile)? do i have to
do it in every image that i put in the pdf?? and the image is gererate
directly in the pdf??how can i do it??
Rob Sargent-4 wrote:
Some jar to which netbeans has access has those classes. Look in the
output of jar tvf and see if any of those has the
named classes. If you find a jar with those classes make sure it's part
of your classpath for you app.
Are you making any calls like ImageIO.write(BufferedImage, "JPEG",
jpegImageFile)?
On 06/13/2011 05:31 PM, Oscar.Flores wrote:
ok i made a test and tell me that the class is missign but maybe what you
say
its rigth and it register the handler
so i gonna register the services so i do this
public static void main(String[] args) throws Exception {
DOMConfigurator.configure("D:/Mis
documentos/NetBeansProjects/Factura/src/factura/log4j.xml");
logger.info("Entering application.");
IIORegistry.getDefaultInstance().registerServiceProvider(new
CLibJPEGImageReaderSpi());
IIORegistry.getDefaultInstance().registerServiceProvider(new
CLibJPEGImageWriterSpi());
also after register my services it telling me that the class
CLibJPEGImageReaderSpi() and CLibJPEGImageWriterSpi() is missing but only
in
command
after register mi service, something more has to be done??
Rob Sargent-4 wrote:
I'm not sure I'm following correctly: does removing the xmlgraphics jar
cause netbeans to behave the same as the command-line run of you app? If
so, I suspect netbeans is registering services for you. Your own code
will have to make a call to one of the
IIORegistry.registerServiceProvider() methods.
On 06/13/2011 05:02 PM, Oscar.Flores wrote:
Ok i get it, actually the ImageIO library i added because i read
in
the
xmlgrapics that if something like the message
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no
suitable loader/converter combination available)appear i have to add
the
jar
file to the classpath but that all it say no configuration or anything,
then
i delete the imagenIO libs and still i have the same output in netbeans
so
xmlgrapics seem to have the problem in the plugins or i have to
configure
something
Rob Sargent-4 wrote:
Then it seems to me netbeans (if it's producing good output ==
assumptionA) is still using something that the command-line isn't.
And given assumptionA, you're java code is correct in terms of FOP and
your configuration isn't for ImageIO. Show your ImageIO related code
and are you sure it's in your app. Use the logger to show a message
when you add your loader. Or list all ImageIO services:
IIORegistry.getServiceProviders()
On 06/13/2011 03:01 PM, Oscar.Flores wrote:
ok well i put the xml in scr of my proyect i see that i still have
the
same
issues of the image render of any image i dont now if the xml its in
place i
put the code down to see if something its missing
15:45:07,827 ERROR [render] Error while processing image:
c:\cfd\nombregp.bmp (i
mage/bmp)
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no
suitab
le loader/converter combination available) for c:\cfd\nombregp.bmp
(image/bmp)
at
org.apache.xmlgraphics.image.loader.ImageManager.getImage(ImageManage
import mx.bigdata.sat.cfd.schema.Comprobante;
import mx.bigdata.sat.cfd.CFDv2;
import mx.bigdata.sat.security.KeyLoader;
import org.jdom.*;
import org.jdom.input.SAXBuilder;
import org.jdom.output.XMLOutputter;
import org.jdom.output.Format;
import org.jdom.transform.JDOMSource;
//Java
import java.io.File;
import java.io.OutputStream;
//JAXP
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.Source;
import javax.xml.transform.Result;
import javax.xml.transform.stream.StreamSource;
import javax.xml.transform.sax.SAXResult;
//FOP
import org.apache.fop.apps.FOUserAgent;
import org.apache.fop.apps.Fop;
import org.apache.fop.apps.FopFactory;
import org.apache.fop.apps.MimeConstants;
//log4j
import org.apache.log4j.*;
import org.apache.log4j.xml.DOMConfigurator;
public final class Main {
@SuppressWarnings("unchecked")
static Logger logger = Logger.getLogger(Main.class);
public static void main(String[] args) throws Exception {
DOMConfigurator.configure("D:/Mis
documento
RE: FOP Extension to handle Wiki Syntax
I'm not sure where I suggested it's not appropriate to consider an
extension. I believe I suggested as you say it might be better to rip
out the function of allowing XML and XSL as input, to provide a separate
convenience jar and/or the code to embed that process, since creating
the FO doesn't involve any fop classes. I already split out that
process in my embedded code if you want to see the 2 step. I don't know
what the wiki text looks like or how common it might be for users to
want to use it as input. If it has a standard format which can be
translated to FO tags and someone wants to write the code to translate
it, it would be nice if code like that could be included as a separate
download on the fop site. I'm not sure what you consider an extension
(plugin?) if they're normally compiled into the fop.jar, if they're
separate jars to download to call as separate tasks, or if they're
separate jars to put on the classpath to accept different types of
values from the mainline fop (ie the -xml -xsl tags)?
I think anything unique to one type of input or output can be a separate
jar with the code kept separately whether you call them extensions,
plugins, or subprojects. They can either be documented second step
processes (output of this = input of that) or extension options (use
-xml and -xsl tags to send input as xml instead of the -fo tag).
From: Glenn Adams [mailto:gl...@skynav.com]
Sent: Tuesday, June 14, 2011 10:47 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Extension to handle Wiki Syntax
You know, given the time spent answering questions about XSL and the
XML+XSL -> XSL-FO front-end ("convenience mechanism") in FOP, I
sometimes wonder if it would be better to rip out that function. Perhaps
then folks would understand better that FOP is fundamentally an XSL-FO
-> output format processor.
As to the original comment, I agree with Eric that is is not appropriate
to consider an FOP extension to accommodate semantics that apply to the
XML+XSL -> XSL-FO 'convenience mapping' mechanism.
G.
On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas
wrote:
It could handle any format you want to write your input in as
long as it
can be translated to FO. If another format is commonly used for
generating FOP input someone would just have to write an input
translator extension.
FOP doesn't even do anything with XML/XSL. It accepts input as
XML/XSL
as a courtesy extension. I wrote a transform with embedded code
starting with data in XML using an XSL to translate it. Then I
figured
out how to generate FO and split that out as a separate step.
That uses
the javax transformer. That step doesn't use any FOP objects.
If you think about it, output could be considered extensions
also. The
main task of the FOP is to input FO and generate the IF. Once
that's
laid out it can take various renderers and generate output so
you have a
PDF extension, a PNG extension, a TIFF extension, etc. They
don't need
to be in the FOP package. Someone who only wants to create PDFs
doesn't
need any classes which create PNGs. If you could break all the
extensions out into subprojects it would make it a few extra
steps to
download but it would be simplified into smaller jars which of
course
load faster if you don't need them all.
-Original Message-
From: Christopher R. Maden [mailto:cr...@maden.org]
Sent: Tuesday, June 14, 2011 9:44 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Extension to handle Wiki Syntax
On 06/14/2011 07:25 AM, kalgon wrote:
> Yes I could transform the XML prior to rendering it to PDF but
that
> wouldn't be as nice and clean as an extension which would take
care of
> everything. Moreover, an extension can be reused whereas
> pre-transforming the XML would require a specific XSLT for
each XML
> schema... definitely not the way I want to go.
Except that's how XSL works, and what FOP implements. FOP takes
exactly[*] 1 kind of input: the FO markup in XML defined by the
XSL
Recommendations.
Nearly all FOP users, as well as users of other XSL formatters,
transform their source either with XSLT or some other tool into
FO for
presentation to the formatter.
If FOP supports MediaWiki syntax natively, why not MoinMoin or
some
other wiki? Why not HTML, DocBook, DITA, CALS, ...?
~Chris
[*] approximately
--
Chris Maden, text nerd http://crism.maden.org/ > "Before
I built
a wall I'd ask to know / What I was walling in or out, / And to
whom I
was like to give offence." - RF, Mending Wall GnuPG Fingerprint:
C6E4
E2A
Re: FOP Extension to handle Wiki Syntax
You're right, I shouldn't have been talking so much about the context of what I want to achieve, the only question that matters to me is: "is it possible for an extension to programmatically add standard FO nodes to the main FO tree, if yes how?". That is all I want to know and until now, nobody has been able to answer that question. I see that FOP does have a lot of extension points but very few documentation about their usage, and I don't mind it this is not the correct way of doing things. I never started the debate about that, I just wanted a simple plain answer to my question. Regards, Kalgon Christopher R. Maden wrote: > > On 06/14/2011 11:23 AM, kalgon wrote: >> I understand but if we want to be strict, XSLT only transform from XML to >> another format (often XML but also Text). In my case wiki syntax is not >> XML >> so we could say it shouldn't be transformed through XSLT. > > Text nodes are part of XML... XSLT can handle processing the contents of > those text nodes. > > However, it’s not always the best tool for doing that. I would probably > write something in your language-of-choice that takes in an XML tree and > writes it out identically, except for upgrading the free-text markup. > There are converters out there to do it... the Freebase BFG project used > one written by one of the original Wikipedia markup designers... see > https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske >. > > This has gotten off-topic for FOP. If you decide to do this in XSLT, > see http://www.mulberrytech.com/xsl/xsl-list/ >. Otherwise, see > the discussion fora for whatever other programming language you’re using. > > ~Chris > -- > Chris Maden, text nerd http://crism.maden.org/ > > “Before I built a wall I’d ask to know / What I was walling in or > out, / And to whom I was like to give offence.” — RF, Mending Wall > GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > -- View this message in context: http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31844121.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
On 06/14/2011 11:23 AM, kalgon wrote: > I understand but if we want to be strict, XSLT only transform from XML to > another format (often XML but also Text). In my case wiki syntax is not XML > so we could say it shouldn't be transformed through XSLT. Text nodes are part of XML... XSLT can handle processing the contents of those text nodes. However, it’s not always the best tool for doing that. I would probably write something in your language-of-choice that takes in an XML tree and writes it out identically, except for upgrading the free-text markup. There are converters out there to do it... the Freebase BFG project used one written by one of the original Wikipedia markup designers... see https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske >. This has gotten off-topic for FOP. If you decide to do this in XSLT, see http://www.mulberrytech.com/xsl/xsl-list/ >. Otherwise, see the discussion fora for whatever other programming language you’re using. ~Chris -- Chris Maden, text nerd http://crism.maden.org/ > “Before I built a wall I’d ask to know / What I was walling in or out, / And to whom I was like to give offence.” — RF, Mending Wall GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
>> An alternative to writing a FOP extension would be to write an
>> XSLT/XPath extension that handles the wiki syntax; instead of simply
>> copying the textual content of the source element, do something like:
>> .
That's the practical solution but I always try to avoid manipulating XML
like Strings (there could be namespace issues).
I think that if I can't write an extension to do what I want, I will go that
way.
Regards,
Kalgon
Sergiu Dumitriu-2 wrote:
>
> On 06/14/2011 04:46 PM, Glenn Adams wrote:
>> You know, given the time spent answering questions about XSL and the
>> XML+XSL -> XSL-FO front-end ("convenience mechanism") in FOP, I
>> sometimes wonder if it would be better to rip out that function. Perhaps
>> then folks would understand better that FOP is fundamentally an XSL-FO
>> -> output format processor.
>>
>> As to the original comment, I agree with Eric that is is not appropriate
>> to consider an FOP extension to accommodate semantics that apply to the
>> XML+XSL -> XSL-FO 'convenience mapping' mechanism.
>
> On the other hand, XSLT is not the best language for implementing wiki
> syntax rendering either.
>
> An alternative to writing a FOP extension would be to write an
> XSLT/XPath extension that handles the wiki syntax; instead of simply
> copying the textual content of the source element, do something like:
> .
>
> http://xml.apache.org/xalan-j/xpath_apis.html#functionresolver explains
> a bit what's needed to write a custom XPath function. You could use an
> existing Java library for wiki syntax rendering, such as
> http://rendering.xwiki.org/
>
>> G.
>>
>> On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas > > wrote:
>>
>> It could handle any format you want to write your input in as long as
>> it
>> can be translated to FO. If another format is commonly used for
>> generating FOP input someone would just have to write an input
>> translator extension.
>>
>> FOP doesn't even do anything with XML/XSL. It accepts input as
>> XML/XSL
>> as a courtesy extension. I wrote a transform with embedded code
>> starting with data in XML using an XSL to translate it. Then I
>> figured
>> out how to generate FO and split that out as a separate step. That
>> uses
>> the javax transformer. That step doesn't use any FOP objects.
>>
>> If you think about it, output could be considered extensions also.
>> The
>> main task of the FOP is to input FO and generate the IF. Once that's
>> laid out it can take various renderers and generate output so you
>> have a
>> PDF extension, a PNG extension, a TIFF extension, etc. They don't
>> need
>> to be in the FOP package. Someone who only wants to create PDFs
>> doesn't
>> need any classes which create PNGs. If you could break all the
>> extensions out into subprojects it would make it a few extra steps to
>> download but it would be simplified into smaller jars which of course
>> load faster if you don't need them all.
>>
>>
>> -Original Message-
>> From: Christopher R. Maden [mailto:cr...@maden.org
>> ]
>> Sent: Tuesday, June 14, 2011 9:44 AM
>> To: fop-users@xmlgraphics.apache.org
>>
>> Subject: Re: FOP Extension to handle Wiki Syntax
>>
>> On 06/14/2011 07:25 AM, kalgon wrote:
>> > Yes I could transform the XML prior to rendering it to PDF but
>> that
>> > wouldn't be as nice and clean as an extension which would take
>> care of
>>
>> > everything. Moreover, an extension can be reused whereas
>> > pre-transforming the XML would require a specific XSLT for each
>> XML
>> > schema... definitely not the way I want to go.
>>
>> Except that's how XSL works, and what FOP implements. FOP takes
>> exactly[*] 1 kind of input: the FO markup in XML defined by the XSL
>> Recommendations.
>>
>> Nearly all FOP users, as well as users of other XSL formatters,
>> transform their source either with XSLT or some other tool into FO
>> for
>> presentation to the formatter.
>>
>> If FOP supports MediaWiki syntax natively, why not MoinMoin or some
>> other wiki? Why not HTML, DocBook, DITA, CALS, ...?
>>
>> ~Chris
>>
>> [*] approximately
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
>
>
--
View this message in context:
http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843863.html
Sent from the FOP - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h
Re: FOP Extension to handle Wiki Syntax
>>You know, given the time spent answering questions about XSL and the
XML+XSL -> XSL-FO front-end
>>("convenience mechanism") in FOP, I sometimes wonder if it would be better
to rip out that function.
>>Perhaps then folks would understand better that FOP is fundamentally an
XSL-FO -> output format
>>processor.
>>As to the original comment, I agree with Eric that is is not appropriate
to consider an FOP extension to
>>accommodate semantics that apply to the XML+XSL -> XSL-FO 'convenience
mapping' mechanism.
I understand but if we want to be strict, XSLT only transform from XML to
another format (often XML but also Text). In my case wiki syntax is not XML
so we could say it shouldn't be transformed through XSLT.
Regards,
Kalgon
Glenn Adams-2 wrote:
>
> You know, given the time spent answering questions about XSL and the
> XML+XSL
> -> XSL-FO front-end ("convenience mechanism") in FOP, I sometimes wonder
> if
> it would be better to rip out that function. Perhaps then folks would
> understand better that FOP is fundamentally an XSL-FO -> output format
> processor.
>
> As to the original comment, I agree with Eric that is is not appropriate
> to
> consider an FOP extension to accommodate semantics that apply to the
> XML+XSL
> -> XSL-FO 'convenience mapping' mechanism.
>
> G.
>
> On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas
> wrote:
>
>> It could handle any format you want to write your input in as long as it
>> can be translated to FO. If another format is commonly used for
>> generating FOP input someone would just have to write an input
>> translator extension.
>>
>> FOP doesn't even do anything with XML/XSL. It accepts input as XML/XSL
>> as a courtesy extension. I wrote a transform with embedded code
>> starting with data in XML using an XSL to translate it. Then I figured
>> out how to generate FO and split that out as a separate step. That uses
>> the javax transformer. That step doesn't use any FOP objects.
>>
>> If you think about it, output could be considered extensions also. The
>> main task of the FOP is to input FO and generate the IF. Once that's
>> laid out it can take various renderers and generate output so you have a
>> PDF extension, a PNG extension, a TIFF extension, etc. They don't need
>> to be in the FOP package. Someone who only wants to create PDFs doesn't
>> need any classes which create PNGs. If you could break all the
>> extensions out into subprojects it would make it a few extra steps to
>> download but it would be simplified into smaller jars which of course
>> load faster if you don't need them all.
>>
>>
>> -Original Message-
>> From: Christopher R. Maden [mailto:cr...@maden.org]
>> Sent: Tuesday, June 14, 2011 9:44 AM
>> To: fop-users@xmlgraphics.apache.org
>> Subject: Re: FOP Extension to handle Wiki Syntax
>>
>> On 06/14/2011 07:25 AM, kalgon wrote:
>> > Yes I could transform the XML prior to rendering it to PDF but that
>> > wouldn't be as nice and clean as an extension which would take care of
>>
>> > everything. Moreover, an extension can be reused whereas
>> > pre-transforming the XML would require a specific XSLT for each XML
>> > schema... definitely not the way I want to go.
>>
>> Except that's how XSL works, and what FOP implements. FOP takes
>> exactly[*] 1 kind of input: the FO markup in XML defined by the XSL
>> Recommendations.
>>
>> Nearly all FOP users, as well as users of other XSL formatters,
>> transform their source either with XSLT or some other tool into FO for
>> presentation to the formatter.
>>
>> If FOP supports MediaWiki syntax natively, why not MoinMoin or some
>> other wiki? Why not HTML, DocBook, DITA, CALS, ...?
>>
>> ~Chris
>>
>> [*] approximately
>> --
>> Chris Maden, text nerd http://crism.maden.org/ > "Before I built
>> a wall I'd ask to know / What I was walling in or out, / And to whom I
>> was like to give offence." - RF, Mending Wall GnuPG Fingerprint: C6E4
>> E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319
>>
>> -
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843807.html
Sent from the FOP - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
Thanks for the explanation about MediaWiki: the term natively led me to think that FOP already had support for MediaWiki syntax. As I was talking about an extension, I didn't see how it could be done natively. So if the WIKI->FO-XML transformation does not belong to FOP, it surely belongs to the transformation part which comes before rendering. But then, I should use Saxon or Xalan specific extensions or does javax.xml.transform provide an unified way to do such a thing? I have currently no idea on how to do that but I suppose the wiki parsing routine will have to be called from inside the stylesheet and I have had bad experiences trying to call java code from xslt. And if javax.xml.transform does not provide a standard way to do that, I will have to create specific extensions for each xslt library (Saxon and Xalan). If I could do it directly through a FOP extension, I would not have those problems. So, now that I understand that such a processing is better done outside FOP, do you think there's a way I could do it inside though an extension? :-) If somebody has a simple example of how an extension could programmatically create a FOText inside a Block, I think I could handle the rest. Regards, Xavier Christopher R. Maden wrote: > > On 06/14/2011 10:15 AM, kalgon wrote: >> But then, what is the purpose of extensions? There are several >> extensions which generate barcodes (barcode4j, zxing-fop-qrcode)... >> so if I follow your reasoning, we should not use those and rather >> pre-generate the images and use fo:external-graphic, right? > > There isn’t anything in the XSL Recommendation about barcodes, so a > barcode extension made sense. True, graphics could have been used, but > barcodes make a lot of sense as formatting artifacts as well. > > The MediaWiki markup for which you’re asking involves headings, > paragraphs, and lists, which are already supported by XSL. No extension > is needed to provide the functionality. > >> I don't see what you're talking about FOP supporting natively >> MediaWiki. How does it support MediaWiki? > > It doesn’t. That’s what you are asking for. (Remember that “wiki” is a > concept of user-edited Web sites; specific kinds of wiki software use > different markup. Wikipedia and the other Wikimedia Foundation sites > use software called MediaWiki.) > >> What I want to do is create an extension which can create a subtree >> of the FO tree (and reusing basic nodes like Block, Table, FOText) >> but I can't find any documentation explaining how to do that (if it's >> possible). I'd prefer an extension doing the wiki->fo transformation >> in one pass instead of having to write two XSL's with intermediate >> results: >> I prefer having a self-contained extension which does all the work >> for me. > > That kind of encapsulated transformation makes a lot of sense. However, > like other pre-FO transformations, it does not belong in FOP. FOP > starts with XSL FO markup; transformations come before that. > > ~Chris > -- > Chris Maden, text nerd http://crism.maden.org/ > > “Before I built a wall I’d ask to know / What I was walling in or > out, / And to whom I was like to give offence.” — RF, Mending Wall > GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > -- View this message in context: http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843733.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
On 06/14/2011 04:46 PM, Glenn Adams wrote:
You know, given the time spent answering questions about XSL and the
XML+XSL -> XSL-FO front-end ("convenience mechanism") in FOP, I
sometimes wonder if it would be better to rip out that function. Perhaps
then folks would understand better that FOP is fundamentally an XSL-FO
-> output format processor.
As to the original comment, I agree with Eric that is is not appropriate
to consider an FOP extension to accommodate semantics that apply to the
XML+XSL -> XSL-FO 'convenience mapping' mechanism.
On the other hand, XSLT is not the best language for implementing wiki
syntax rendering either.
An alternative to writing a FOP extension would be to write an
XSLT/XPath extension that handles the wiki syntax; instead of simply
copying the textual content of the source element, do something like:
.
http://xml.apache.org/xalan-j/xpath_apis.html#functionresolver explains
a bit what's needed to write a custom XPath function. You could use an
existing Java library for wiki syntax rendering, such as
http://rendering.xwiki.org/
G.
On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas mailto:edoug...@blockhouse.com>> wrote:
It could handle any format you want to write your input in as long as it
can be translated to FO. If another format is commonly used for
generating FOP input someone would just have to write an input
translator extension.
FOP doesn't even do anything with XML/XSL. It accepts input as XML/XSL
as a courtesy extension. I wrote a transform with embedded code
starting with data in XML using an XSL to translate it. Then I figured
out how to generate FO and split that out as a separate step. That uses
the javax transformer. That step doesn't use any FOP objects.
If you think about it, output could be considered extensions also. The
main task of the FOP is to input FO and generate the IF. Once that's
laid out it can take various renderers and generate output so you have a
PDF extension, a PNG extension, a TIFF extension, etc. They don't need
to be in the FOP package. Someone who only wants to create PDFs doesn't
need any classes which create PNGs. If you could break all the
extensions out into subprojects it would make it a few extra steps to
download but it would be simplified into smaller jars which of course
load faster if you don't need them all.
-Original Message-
From: Christopher R. Maden [mailto:cr...@maden.org
]
Sent: Tuesday, June 14, 2011 9:44 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Extension to handle Wiki Syntax
On 06/14/2011 07:25 AM, kalgon wrote:
> Yes I could transform the XML prior to rendering it to PDF but that
> wouldn't be as nice and clean as an extension which would take
care of
> everything. Moreover, an extension can be reused whereas
> pre-transforming the XML would require a specific XSLT for each XML
> schema... definitely not the way I want to go.
Except that's how XSL works, and what FOP implements. FOP takes
exactly[*] 1 kind of input: the FO markup in XML defined by the XSL
Recommendations.
Nearly all FOP users, as well as users of other XSL formatters,
transform their source either with XSLT or some other tool into FO for
presentation to the formatter.
If FOP supports MediaWiki syntax natively, why not MoinMoin or some
other wiki? Why not HTML, DocBook, DITA, CALS, ...?
~Chris
[*] approximately
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
You know, given the time spent answering questions about XSL and the XML+XSL
-> XSL-FO front-end ("convenience mechanism") in FOP, I sometimes wonder if
it would be better to rip out that function. Perhaps then folks would
understand better that FOP is fundamentally an XSL-FO -> output format
processor.
As to the original comment, I agree with Eric that is is not appropriate to
consider an FOP extension to accommodate semantics that apply to the XML+XSL
-> XSL-FO 'convenience mapping' mechanism.
G.
On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas wrote:
> It could handle any format you want to write your input in as long as it
> can be translated to FO. If another format is commonly used for
> generating FOP input someone would just have to write an input
> translator extension.
>
> FOP doesn't even do anything with XML/XSL. It accepts input as XML/XSL
> as a courtesy extension. I wrote a transform with embedded code
> starting with data in XML using an XSL to translate it. Then I figured
> out how to generate FO and split that out as a separate step. That uses
> the javax transformer. That step doesn't use any FOP objects.
>
> If you think about it, output could be considered extensions also. The
> main task of the FOP is to input FO and generate the IF. Once that's
> laid out it can take various renderers and generate output so you have a
> PDF extension, a PNG extension, a TIFF extension, etc. They don't need
> to be in the FOP package. Someone who only wants to create PDFs doesn't
> need any classes which create PNGs. If you could break all the
> extensions out into subprojects it would make it a few extra steps to
> download but it would be simplified into smaller jars which of course
> load faster if you don't need them all.
>
>
> -Original Message-
> From: Christopher R. Maden [mailto:cr...@maden.org]
> Sent: Tuesday, June 14, 2011 9:44 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP Extension to handle Wiki Syntax
>
> On 06/14/2011 07:25 AM, kalgon wrote:
> > Yes I could transform the XML prior to rendering it to PDF but that
> > wouldn't be as nice and clean as an extension which would take care of
>
> > everything. Moreover, an extension can be reused whereas
> > pre-transforming the XML would require a specific XSLT for each XML
> > schema... definitely not the way I want to go.
>
> Except that's how XSL works, and what FOP implements. FOP takes
> exactly[*] 1 kind of input: the FO markup in XML defined by the XSL
> Recommendations.
>
> Nearly all FOP users, as well as users of other XSL formatters,
> transform their source either with XSLT or some other tool into FO for
> presentation to the formatter.
>
> If FOP supports MediaWiki syntax natively, why not MoinMoin or some
> other wiki? Why not HTML, DocBook, DITA, CALS, ...?
>
> ~Chris
>
> [*] approximately
> --
> Chris Maden, text nerd http://crism.maden.org/ > "Before I built
> a wall I'd ask to know / What I was walling in or out, / And to whom I
> was like to give offence." - RF, Mending Wall GnuPG Fingerprint: C6E4
> E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
>
Re: FOP Extension to handle Wiki Syntax
On 06/14/2011 10:15 AM, kalgon wrote: > But then, what is the purpose of extensions? There are several > extensions which generate barcodes (barcode4j, zxing-fop-qrcode)... > so if I follow your reasoning, we should not use those and rather > pre-generate the images and use fo:external-graphic, right? There isn’t anything in the XSL Recommendation about barcodes, so a barcode extension made sense. True, graphics could have been used, but barcodes make a lot of sense as formatting artifacts as well. The MediaWiki markup for which you’re asking involves headings, paragraphs, and lists, which are already supported by XSL. No extension is needed to provide the functionality. > I don't see what you're talking about FOP supporting natively > MediaWiki. How does it support MediaWiki? It doesn’t. That’s what you are asking for. (Remember that “wiki” is a concept of user-edited Web sites; specific kinds of wiki software use different markup. Wikipedia and the other Wikimedia Foundation sites use software called MediaWiki.) > What I want to do is create an extension which can create a subtree > of the FO tree (and reusing basic nodes like Block, Table, FOText) > but I can't find any documentation explaining how to do that (if it's > possible). I'd prefer an extension doing the wiki->fo transformation > in one pass instead of having to write two XSL's with intermediate > results: > I prefer having a self-contained extension which does all the work > for me. That kind of encapsulated transformation makes a lot of sense. However, like other pre-FO transformations, it does not belong in FOP. FOP starts with XSL FO markup; transformations come before that. ~Chris -- Chris Maden, text nerd http://crism.maden.org/ > “Before I built a wall I’d ask to know / What I was walling in or out, / And to whom I was like to give offence.” — RF, Mending Wall GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Problems with FOP and image
No i dont, and that weird jejeje netbeans seems to do that for me, so the
calls like ImageIO.write(BufferedImage, "JPEG", jpegImageFile)? do i have to
do it in every image that i put in the pdf?? and the image is gererate
directly in the pdf??how can i do it??
Rob Sargent-4 wrote:
>
> Some jar to which netbeans has access has those classes. Look in the
> output of jar tvf and see if any of those has the
> named classes. If you find a jar with those classes make sure it's part
> of your classpath for you app.
>
> Are you making any calls like ImageIO.write(BufferedImage, "JPEG",
> jpegImageFile)?
>
> On 06/13/2011 05:31 PM, Oscar.Flores wrote:
>> ok i made a test and tell me that the class is missign but maybe what you
>> say
>> its rigth and it register the handler
>> so i gonna register the services so i do this
>>
>> public static void main(String[] args) throws Exception {
>> DOMConfigurator.configure("D:/Mis
>> documentos/NetBeansProjects/Factura/src/factura/log4j.xml");
>> logger.info("Entering application.");
>>IIORegistry.getDefaultInstance().registerServiceProvider(new
>> CLibJPEGImageReaderSpi());
>>IIORegistry.getDefaultInstance().registerServiceProvider(new
>> CLibJPEGImageWriterSpi());
>>
>> also after register my services it telling me that the class
>> CLibJPEGImageReaderSpi() and CLibJPEGImageWriterSpi() is missing but only
>> in
>> command
>>
>> after register mi service, something more has to be done??
>>
>>
>> Rob Sargent-4 wrote:
>>> I'm not sure I'm following correctly: does removing the xmlgraphics jar
>>> cause netbeans to behave the same as the command-line run of you app? If
>>> so, I suspect netbeans is registering services for you. Your own code
>>> will have to make a call to one of the
>>> IIORegistry.registerServiceProvider() methods.
>>>
>>> On 06/13/2011 05:02 PM, Oscar.Flores wrote:
Ok i get it, actually the ImageIO library i added because i read
in
the
xmlgrapics that if something like the message
org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
(no
suitable loader/converter combination available)appear i have to add
the
jar
file to the classpath but that all it say no configuration or anything,
then
i delete the imagenIO libs and still i have the same output in netbeans
so
xmlgrapics seem to have the problem in the plugins or i have to
configure
something
Rob Sargent-4 wrote:
> Then it seems to me netbeans (if it's producing good output ==
> assumptionA) is still using something that the command-line isn't.
>
> And given assumptionA, you're java code is correct in terms of FOP and
> your configuration isn't for ImageIO. Show your ImageIO related code
> and are you sure it's in your app. Use the logger to show a message
> when you add your loader. Or list all ImageIO services:
> IIORegistry.getServiceProviders()
>
> On 06/13/2011 03:01 PM, Oscar.Flores wrote:
>> ok well i put the xml in scr of my proyect i see that i still have
>> the
>> same
>> issues of the image render of any image i dont now if the xml its in
>> place i
>> put the code down to see if something its missing
>>
>> 15:45:07,827 ERROR [render] Error while processing image:
>> c:\cfd\nombregp.bmp (i
>> mage/bmp)
>> org.apache.xmlgraphics.image.loader.ImageException: Cannot load image
>> (no
>> suitab
>> le loader/converter combination available) for c:\cfd\nombregp.bmp
>> (image/bmp)
>>at
>> org.apache.xmlgraphics.image.loader.ImageManager.getImage(ImageManage
>>
>>
>>
>> import mx.bigdata.sat.cfd.schema.Comprobante;
>> import mx.bigdata.sat.cfd.CFDv2;
>> import mx.bigdata.sat.security.KeyLoader;
>> import org.jdom.*;
>> import org.jdom.input.SAXBuilder;
>> import org.jdom.output.XMLOutputter;
>> import org.jdom.output.Format;
>> import org.jdom.transform.JDOMSource;
>> //Java
>> import java.io.File;
>> import java.io.OutputStream;
>>
>> //JAXP
>> import javax.xml.transform.Transformer;
>> import javax.xml.transform.TransformerFactory;
>> import javax.xml.transform.Source;
>> import javax.xml.transform.Result;
>> import javax.xml.transform.stream.StreamSource;
>> import javax.xml.transform.sax.SAXResult;
>>
>> //FOP
>> import org.apache.fop.apps.FOUserAgent;
>> import org.apache.fop.apps.Fop;
>> import org.apache.fop.apps.FopFactory;
>> import org.apache.fop.apps.MimeConstants;
>>
>> //log4j
>> import org.apache.log4j.*;
>> import org.apache.log4j.xml.DOMConfigurator;
>>
>> public final class Main {
>>@SuppressWarnings("unchecked")
>>static Logger logger = Logger.getLogger(Main.class);
RE: FOP Extension to handle Wiki Syntax
It could handle any format you want to write your input in as long as it can be translated to FO. If another format is commonly used for generating FOP input someone would just have to write an input translator extension. FOP doesn't even do anything with XML/XSL. It accepts input as XML/XSL as a courtesy extension. I wrote a transform with embedded code starting with data in XML using an XSL to translate it. Then I figured out how to generate FO and split that out as a separate step. That uses the javax transformer. That step doesn't use any FOP objects. If you think about it, output could be considered extensions also. The main task of the FOP is to input FO and generate the IF. Once that's laid out it can take various renderers and generate output so you have a PDF extension, a PNG extension, a TIFF extension, etc. They don't need to be in the FOP package. Someone who only wants to create PDFs doesn't need any classes which create PNGs. If you could break all the extensions out into subprojects it would make it a few extra steps to download but it would be simplified into smaller jars which of course load faster if you don't need them all. -Original Message- From: Christopher R. Maden [mailto:cr...@maden.org] Sent: Tuesday, June 14, 2011 9:44 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP Extension to handle Wiki Syntax On 06/14/2011 07:25 AM, kalgon wrote: > Yes I could transform the XML prior to rendering it to PDF but that > wouldn't be as nice and clean as an extension which would take care of > everything. Moreover, an extension can be reused whereas > pre-transforming the XML would require a specific XSLT for each XML > schema... definitely not the way I want to go. Except that's how XSL works, and what FOP implements. FOP takes exactly[*] 1 kind of input: the FO markup in XML defined by the XSL Recommendations. Nearly all FOP users, as well as users of other XSL formatters, transform their source either with XSLT or some other tool into FO for presentation to the formatter. If FOP supports MediaWiki syntax natively, why not MoinMoin or some other wiki? Why not HTML, DocBook, DITA, CALS, ...? ~Chris [*] approximately -- Chris Maden, text nerd http://crism.maden.org/ > "Before I built a wall I'd ask to know / What I was walling in or out, / And to whom I was like to give offence." - RF, Mending Wall GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
But then, what is the purpose of extensions? There are several extensions which generate barcodes (barcode4j, zxing-fop-qrcode)... so if I follow your reasoning, we should not use those and rather pre-generate the images and use fo:external-graphic, right? I don't see what you're talking about FOP supporting natively MediaWiki. How does it support MediaWiki? What I want to do is create an extension which can create a subtree of the FO tree (and reusing basic nodes like Block, Table, FOText) but I can't find any documentation explaining how to do that (if it's possible). I'd prefer an extension doing the wiki->fo transformation in one pass instead of having to write two XSL's with intermediate results: * item1 * item2 transformed to: ... ... and then only transformed into full fo: ... I prefer having a self-contained extension which does all the work for me. Regards, Kalgon Christopher R. Maden wrote: > > On 06/14/2011 07:25 AM, kalgon wrote: >> Yes I could transform the XML prior to rendering it to PDF but that >> wouldn't be as nice and clean as an extension which would take care >> of everything. Moreover, an extension can be reused whereas >> pre-transforming the XML would require a specific XSLT for each XML >> schema... definitely not the way I want to go. > > Except that’s how XSL works, and what FOP implements. FOP takes > exactly[*] 1 kind of input: the FO markup in XML defined by the XSL > Recommendations. > > Nearly all FOP users, as well as users of other XSL formatters, > transform their source either with XSLT or some other tool into FO for > presentation to the formatter. > > If FOP supports MediaWiki syntax natively, why not MoinMoin or some > other wiki? Why not HTML, DocBook, DITA, CALS, ...? > > ~Chris > > [*] approximately > -- > Chris Maden, text nerd http://crism.maden.org/ > > “Before I built a wall I’d ask to know / What I was walling in or > out, / And to whom I was like to give offence.” — RF, Mending Wall > GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > -- View this message in context: http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843185.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Extension to handle Wiki Syntax
On 06/14/2011 07:25 AM, kalgon wrote: > Yes I could transform the XML prior to rendering it to PDF but that > wouldn't be as nice and clean as an extension which would take care > of everything. Moreover, an extension can be reused whereas > pre-transforming the XML would require a specific XSLT for each XML > schema... definitely not the way I want to go. Except that’s how XSL works, and what FOP implements. FOP takes exactly[*] 1 kind of input: the FO markup in XML defined by the XSL Recommendations. Nearly all FOP users, as well as users of other XSL formatters, transform their source either with XSLT or some other tool into FO for presentation to the formatter. If FOP supports MediaWiki syntax natively, why not MoinMoin or some other wiki? Why not HTML, DocBook, DITA, CALS, ...? ~Chris [*] approximately -- Chris Maden, text nerd http://crism.maden.org/ > “Before I built a wall I’d ask to know / What I was walling in or out, / And to whom I was like to give offence.” — RF, Mending Wall GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: FOP Extension to handle Wiki Syntax
Yes I could transform the XML prior to rendering it to PDF but that wouldn't be as nice and clean as an extension which would take care of everything. Moreover, an extension can be reused whereas pre-transforming the XML would require a specific XSLT for each XML schema... definitely not the way I want to go. Regards, Kalgon Theresa Jayne Forster wrote: > > Can't you just XSLT the incoming document ? > > > Kindest regards > > > Theresa Forster > Senior Software Developer > -Original Message- > From: kalgon [mailto:kal...@hotmail.com] > Sent: 14 June 2011 11:09 > To: fop-users@xmlgraphics.apache.org > Subject: FOP Extension to handle Wiki Syntax > > > Hi, > > I would like to write a FOP extension to render text written in wiki > syntax: > > > > > > > > = title = > * item > * item > > > > What I would like to know is how I can build a tree of FONodes (blocks, > text, table...) programmatically while parsing my wiki text and feed that > tree to the FOP engine. I've been looking at ElementMapping, XMLHandler > and > the likes but I can't get a good grip at how those are working. > > If somebody could point me to a good and complete tutorial on FOP > extensions > or send me a nice example of how to do it, that would help me a lot! > > Thanks, > > Kalgon > > -- > View this message in context: > http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p3184140 > 3.html > Sent from the FOP - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > > - > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1382 / Virus Database: 1511/3683 - Release Date: 06/05/11 > Internal Virus Database is out of date. > > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > -- View this message in context: http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31841886.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: FOP Extension to handle Wiki Syntax
Can't you just XSLT the incoming document ? Kindest regards Theresa Forster Senior Software Developer -Original Message- From: kalgon [mailto:kal...@hotmail.com] Sent: 14 June 2011 11:09 To: fop-users@xmlgraphics.apache.org Subject: FOP Extension to handle Wiki Syntax Hi, I would like to write a FOP extension to render text written in wiki syntax: = title = * item * item What I would like to know is how I can build a tree of FONodes (blocks, text, table...) programmatically while parsing my wiki text and feed that tree to the FOP engine. I've been looking at ElementMapping, XMLHandler and the likes but I can't get a good grip at how those are working. If somebody could point me to a good and complete tutorial on FOP extensions or send me a nice example of how to do it, that would help me a lot! Thanks, Kalgon -- View this message in context: http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p3184140 3.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1382 / Virus Database: 1511/3683 - Release Date: 06/05/11 Internal Virus Database is out of date. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP Extension to handle Wiki Syntax
Hi, I would like to write a FOP extension to render text written in wiki syntax: = title = * item * item What I would like to know is how I can build a tree of FONodes (blocks, text, table...) programmatically while parsing my wiki text and feed that tree to the FOP engine. I've been looking at ElementMapping, XMLHandler and the likes but I can't get a good grip at how those are working. If somebody could point me to a good and complete tutorial on FOP extensions or send me a nice example of how to do it, that would help me a lot! Thanks, Kalgon -- View this message in context: http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31841403.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Color fade on SVG with gradients
After seeing the thread for "Text fill color in external SVG is not preserved" I thought I would raise this issue we are seeing, With small numbers of gradients, we have no problems but we have a gradient full logo with many gradients, With normal viewers it looks exactly as intended (with a lighter front). After this though when placing in a PDF the svg loses color and looks faded missing the top color after processing, I read that this may be due to color processing changes, from RGB->CMYK->RGB or something like that. Or has anyone a better solution? Kindest regards Theresa Forster Senior Software Developer
