Re: reference-orientation
Sure, you can rotate text in SVG documents embedded in fo:instream-foreign-object elements. On 28.02.2006 07:53:51 Andre Groeneveld wrote: > Is there by any chance another way of rotating text in the FOP version > that I have? > Thanks, > > Andre groeneveld > IS Services > Tel: (011) 489 - 4117 > Fax: (011) 489 - 4128 > > -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Sent: 27 February 2006 06:01 PM > To: fop-users@xmlgraphics.apache.org > Subject: Re: reference-orientation > > Ask yourself what "not implemented" means. FOP does not support it, > obviously. The good thing about your second question today is that I > know now which version of FOP you're using: 0.20.5. If you upgrade to > the latest release 0.91beta you can use reference-orientation because > it's implemented, there. Now, over to your previous question... > > On 27.02.2006 16:53:20 Andre Groeneveld wrote: > > Hi all, > > When using reference-orientation, can any one please tell me why I > keep > > getting an error saying: property - "reference-orientation" is not > > implemented yet. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: reference-orientation
Is there by any chance another way of rotating text in the FOP version
that I have?
Thanks,
Andre groeneveld
IS Services
Tel: (011) 489 - 4117
Fax: (011) 489 - 4128
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: 27 February 2006 06:01 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: reference-orientation
Ask yourself what "not implemented" means. FOP does not support it,
obviously. The good thing about your second question today is that I
know now which version of FOP you're using: 0.20.5. If you upgrade to
the latest release 0.91beta you can use reference-orientation because
it's implemented, there. Now, over to your previous question...
On 27.02.2006 16:53:20 Andre Groeneveld wrote:
> Hi all,
> When using reference-orientation, can any one please tell me why I
keep
> getting an error saying: property - "reference-orientation" is not
> implemented yet.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Confidentiality Caution and Disclaimer
This message and/or any attachment thereto ("the message")
contains privileged and confidential information intended
only for the recipient named above.
If you are not the intended recipient of this message,
please erase it permanently once you have notified the
sender, per return e-mail, that you have received the
message in error.
Unless the sender is duly authorised by either the Telesure
Group, or any of its subsidiary companies or I.S Services
("the Group") to send this message and unless the content
of this message is also duly authorised by the Group, any
views expressed in this message are those of the individual
sender and the Group will not accept liability therefore,
nor for any consequential damage arising therefrom.
Any recipient of an unacceptable communication, a chain
letter or offensive material of any nature is requested
to report it to [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping blocks together.
Sorry, im new to FOP, so I didn't know that the version is that
important.
Thanks for all your help.
Andre groeneveld
IS Services
Tel: (011) 489 - 4117
Fax: (011) 489 - 4128
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: 27 February 2006 06:05 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Keeping blocks together.
Due to your second question today, I can easily answer this question,
too. You forgot to tell what FOP version you use. That's VERY important
if you want good and quick answers.
Keep properties are only implemented on table-rows in FOP 0.20.5, so if
you want to keep your table together with some blocks, you need to
upgrade to the latest release (0.91beta). The work-around for 0.20.5 is
to pack your blocks into a table and use the keep properties there. Not
very beautiful but so far it worked for many until the latest release
has been made available.
If you want to know what the individual FOP version can do or can't,
please consult the compliance page:
http://xmlgraphics.apache.org/fop/compliance.html
On 27.02.2006 12:51:36 Andre Groeneveld wrote:
> Can anyone please help; I have 2 blocks and a table, is there anyway
of
> keeping them on the same page? On the table I used
> keep-with-next="always", to write it on the next page if it overflows,
> but if the table gets written to the next page, then the 2blocks also
> has to get written to the next page, is there a way of doing this?
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Confidentiality Caution and Disclaimer
This message and/or any attachment thereto ("the message")
contains privileged and confidential information intended
only for the recipient named above.
If you are not the intended recipient of this message,
please erase it permanently once you have notified the
sender, per return e-mail, that you have received the
message in error.
Unless the sender is duly authorised by either the Telesure
Group, or any of its subsidiary companies or I.S Services
("the Group") to send this message and unless the content
of this message is also duly authorised by the Group, any
views expressed in this message are those of the individual
sender and the Group will not accept liability therefore,
nor for any consequential damage arising therefrom.
Any recipient of an unacceptable communication, a chain
letter or offensive material of any nature is requested
to report it to [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: RTF and table/column widths
- original Nachricht Betreff: Re: RTF and table/column widths Gesendet: Sa 25 Feb 2006 02:43:50 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Feb 23, 2006, at 20:31, [EMAIL PROTECTED] wrote: > > Hi, > > > > (A less important fact is, that list bullets are not rendered > > properly, I had a question mark instead of a bullet. Somewhere I > > have the sample code for rendering fancy bullets to RTF...) > > Hmm... sounds like the much dreaded java.nio.charset.CharsetEncoder- > initial-value question-mark :-) > Is this really an RTF-specific issue AFAYCT? I hope... I dunno right now, but in PDF all the bullets are rendered correctly, so there should be a possibility to render them both from the same character, no matter what font or document format. If it's totally impossible, a simple '-' should be used. Looks better than '?'. I'll look through this, when I finished that proportional width thing... > > If I interpret correctly, docbook uses a fancy Unicode codepoint as > content of a fo:list-item-label somewhere, and this is internally > converted from/into bytes either without explicit encoding (platform > default) or with an explicit encoding... Either way, if the used > encoding scheme does not offer a character for that codepoint, etc. Mkay, but I won't recode the char set only to get rid of the question mark. So I prefer to start every list with a hyphen or whatever symbol is char-set-safe... > > Another possibility may be the encoding in the RTF itself. Have you > tried forcing/changing the encoding in your RTF viewer? [...] Yeah, thought so, too. Maybe during the week I've got enough time to upload some UTF-8 and ISO-8859-1 based documents (FO/RTF). And I'll also have a look at these samples with Wordpad, Word (Office '97) and OpenOffice "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Absolute 'file:' URI scheme bug on Windows?
Jeremias Maerki wrote: > Both url(file:/C:/..) and url(file:///C:/..) work fine in FOP > 0.91beta. Mmh, yes, I just checked this on a local directory. Maybe related to the file permissions, I don't know. I'll investigate further. Thanks, and sorry for the noise, --drkm ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Absolute 'file:' URI scheme bug on Windows?
Hmm, as I said in my other response, I tested locally with 0.91beta and FOP Trunk and it works. I wonder what goes wrong. Are you sure that the URLs generated by Saxon really point to existing files? "Image not available" is only the second error message. Is the first an "UnknownHostException: C" or a FileNotFoundException? On 27.02.2006 17:20:54 Florent Georges wrote: > Florent Georges wrote: > > > I'm using the following to access an SVG file on a Windows > > server: > > > > > Sorry, I forgot to specify the version I use: FOP 0.91beta. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Absolute 'file:' URI scheme bug on Windows?
Both url(file:/C:/..) and url(file:///C:/..) work fine in FOP
0.91beta.
On 27.02.2006 17:08:23 Florent Georges wrote:
> Hi
>
> I'm using the following to access an SVG file on a Windows
> server:
>
>
>
> See the value of the URI (i.e. 'file:/C:/...'). If I use a
> relative URI, starting for example by '../', no problem.
> But with the above URI the file is not found, and I get the
> following error message:
>
> FONode.Image not available: url('file:/C:/.../xx.svg')
>
> The problem is that this URI is generated by the XPath 2.0
> function 'fn:resolve-uri()' (Saxon 8.6.1, but I think this
> behaviour is herited from a standard Java class).
>
> Which is wrong, which is right? FOP or Saxon?
>
> Thanks for your help. Regards,
>
> --drkm
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Absolute 'file:' URI scheme bug on Windows?
Florent Georges wrote: > I'm using the following to access an SVG file on a Windows > server: > Sorry, I forgot to specify the version I use: FOP 0.91beta. Regards, --drkm ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Absolute 'file:' URI scheme bug on Windows?
Hi
I'm using the following to access an SVG file on a Windows
server:
See the value of the URI (i.e. 'file:/C:/...'). If I use a
relative URI, starting for example by '../', no problem.
But with the above URI the file is not found, and I get the
following error message:
FONode.Image not available: url('file:/C:/.../xx.svg')
The problem is that this URI is generated by the XPath 2.0
function 'fn:resolve-uri()' (Saxon 8.6.1, but I think this
behaviour is herited from a standard Java class).
Which is wrong, which is right? FOP or Saxon?
Thanks for your help. Regards,
--drkm
___
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs
exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping blocks together.
Due to your second question today, I can easily answer this question, too. You forgot to tell what FOP version you use. That's VERY important if you want good and quick answers. Keep properties are only implemented on table-rows in FOP 0.20.5, so if you want to keep your table together with some blocks, you need to upgrade to the latest release (0.91beta). The work-around for 0.20.5 is to pack your blocks into a table and use the keep properties there. Not very beautiful but so far it worked for many until the latest release has been made available. If you want to know what the individual FOP version can do or can't, please consult the compliance page: http://xmlgraphics.apache.org/fop/compliance.html On 27.02.2006 12:51:36 Andre Groeneveld wrote: > Can anyone please help; I have 2 blocks and a table, is there anyway of > keeping them on the same page? On the table I used > keep-with-next="always", to write it on the next page if it overflows, > but if the table gets written to the next page, then the 2blocks also > has to get written to the next page, is there a way of doing this? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reference-orientation
Ask yourself what "not implemented" means. FOP does not support it, obviously. The good thing about your second question today is that I know now which version of FOP you're using: 0.20.5. If you upgrade to the latest release 0.91beta you can use reference-orientation because it's implemented, there. Now, over to your previous question... On 27.02.2006 16:53:20 Andre Groeneveld wrote: > Hi all, > When using reference-orientation, can any one please tell me why I keep > getting an error saying: property - "reference-orientation" is not > implemented yet. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reference-orientation
Hi all,
When using reference-orientation, can any one please tell me
why I keep getting an error saying: property - "reference-orientation" is not implemented yet.
Thanks,
Confidentiality Caution and Disclaimer
This message and/or any attachment thereto ("the message")contains
privileged and confidential information intendedonly for the recipient. If you are not the intended recipient of
this message,please erase it permanently once you have notified
thesender, per return e-mail, that you have received themessage in
error.Unless the sender is duly authorised by either the
TelesureGroup, or any of its subsidiary or affiliated companies or I.S Services("the Group") to send
this message and unless the contentof this message is also duly authorised
by the Group, anyviews expressed in this message are those of the
individualsender and the Group will not accept liability therefore,nor
for any consequential damage arising there from.Any recipient of an
unacceptable communication, a chainletter or offensive material of any
nature is requestedto be reported to [EMAIL PROTECTED].
Re: table-layout
OK. I will do that. The list is truly a fine resource. - Original Message - From: "Jay Bryant" <[EMAIL PROTECTED]> To: Sent: Sunday, February 26, 2006 9:18 PM Subject: Re: table-layout Hi, Tracey, The best way is to ask specific questions. Many folks on the list have used FOP to solve heavy-duty, real-world problems. For example, I recently finished the XSL work that lets the Boston Globe use FOP to produce over 4000 pages of distribution reports (which product goes where) every day. We can help you solve similar problems if you can tell us exactly what obstacles you encounter. However, it's hard to give generic advice that means anything, because each problem has its own characteristics. Jay Bryant Bryant Communication Services - Original Message - From: "Tracey Zellmann" <[EMAIL PROTECTED]> To: Sent: Sunday, February 26, 2006 6:18 PM Subject: Re: table-layout Thanks That worked perfectly as well. Now that I seem to at least have FOP working, I want to make better use of its facilities. How can I get a handle on the basic parameters - like these ones that I encounter. The underlying documentation has been helpful to get the examples running, and from those, to get my own applictaion running. However, when I try to delve deeper, things get a bit murky. I must say, this list has been very helpful. I am also impressed at the global scope - makes 24 * 7 almost feasible! - Original Message - From: "Manuel Mall" <[EMAIL PROTECTED]> To: Sent: Sunday, February 26, 2006 6:04 PM Subject: Re: table-layout > On Monday 27 February 2006 02:59, Tracey Zellmann wrote: >> Excellent! That worked like a charm. >> >> Another small question, if you or someone else has a moment. >> >> I am using some spanned cells, but, at least for now, none of my >> table cells have any borders. >> >> I am getting a warning with a TODO >> >> WARNING: TODO Add collapsed border painting for spanned cells >> >> What am I supposed to do? >> > > Try specifying border-collapse="separate" on the table. > > Manuel > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keeping blocks together.
Hi,
Can anyone please help; I have 2 blocks and a table, is there anyway of
keeping them on the same page? On the table I used keep-with-next=”always”,
to write it on the next page if it overflows, but if the table gets written to
the next page, then the 2blocks also has to get written to the next page, is
there a way of doing this?
Thanks,
Confidentiality Caution and Disclaimer
This message and/or any attachment thereto ("the message")contains
privileged and confidential information intendedonly for the recipient. If you are not the intended recipient of
this message,please erase it permanently once you have notified
thesender, per return e-mail, that you have received themessage in
error.Unless the sender is duly authorised by either the
TelesureGroup, or any of its subsidiary or affiliated companies or I.S Services("the Group") to send
this message and unless the contentof this message is also duly authorised
by the Group, anyviews expressed in this message are those of the
individualsender and the Group will not accept liability therefore,nor
for any consequential damage arising there from.Any recipient of an
unacceptable communication, a chainletter or offensive material of any
nature is requestedto be reported to [EMAIL PROTECTED].
Re: AW: AW: Flow Area with explizit height inside an "normal" flow ar ea?
It's not requested by any of my clients and not on my personal priority list, I'm afraid. So: no, not in the near future. But it don't think it would be very hard to implement if you want to do it yourself. I can give you some pointers if you want. On 27.02.2006 08:13:55 news wrote: > Are you going to implement this in one of the next releases? > > -Ursprüngliche Nachricht- > Von: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 23. Februar 2006 13:47 > An: fop-users@xmlgraphics.apache.org > Betreff: Re: AW: Flow Area with explizit height inside an "normal" flow > area? > > With overflow="repeat" (defined in the latest XSL 1.1 CR) I think this could > be done, but this would have to be implemented, first. However, I'm not sure > if you can reliably force every container on a new page if the container's > height is less than half the available content height on a page. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fop trunk svg problems
Jason,
it seems I forgot to disable the "endorsed" directory in my 1.5.0_03 JDK
when I did the test. Sloppy me. Sorry. The problem does occur with
an unpatched 1.5.0_03. All the worse for Sun. :-)
On 24.02.2006 22:07:14 Jason R Briggs wrote:
> Hi Jeremias
>
> I'm running 1.5.0_06 (linux) so it's strange the the problem doesn't
> occur for you with 1.5.0_03. Also seems a bit odd that there would be
> differences between linux and windows (assuming you're using windows)
> xml parser/xslt versions.
>
> Anyway, I copied the jars into endorsed as specified, and indeed that
> does fix the problem. Good news!
>
> Thanks for the prompt reply and your efforts.
>
> Kind regards
> Jason
>
>
> Jeremias Maerki wrote:
> > Horrible! Here's what I found out:
> >
> > It's Sun's fault. :-) Mostly, anyway.
> >
> > I've recently changed FOP to use the JAXP/TRaX API (javax.transform) to
> > build (SVG) DOMs from a SAX stream. If Xalan-J is the primary XSLT
> > implementation, org.apache.xml.utils.DOMBuilder is used internally to
> > build the DOM. So much for the context.
> >
> > The symptom: The BridgeException happens because Batik cannot find the
> > "r" attribute. Batik cannot find the "r" attribute because
> > org.apache.batik.dom.AbstractElement.get(String, String) encounters a
> > mismatch: The "r" attribute has been specified with an empty String ("")
> > as the namespace URI but is now looking for "r" with a null namespace
> > URI. This means that the attribute was set on the DOM element using an
> > empty String in the namespace URI by DOMBuilder.
> >
> > If you let the SAXSVGDocumentFactory (a Batik class) do the same job, an
> > empty String reported by a SAX parser will be converted to a null value.
> > No error happens. So, for SVG, this would be a work-around we could
> > implement.
> >
> > Even the latest Sun JDK 1.4.2_10 contains an ancient version of Apache
> > Xalan-J as its XSLT implementation. With bugs, of course. Xalan-J
> > versions (Apache versions that is) after 2000-12-31 have a change that
> > convert the namespace URI from a null namespace URI to an empty String
> > [1]. (This tells something about how old the code in Sun JDK 1.4.2_10 is).
> > Note, this is actually the opposite of what we would expect, since the
> > DOM Level 2 specification says that null represents the right value for
> > an attribute that is in no namespace. However, the SAX AttributesImpl [2]
> > expects an empty String to indicate the same. It's interesting thing is
> > a change [3] on 2002-07-10 which suddenly starts to convert empty
> > Strings to null values (which is actually my expectation).
> >
> > I see several ways to go:
> > - The easiest (and my recommendation) is to use the endorsed standards
> > override mechanism to replace the XML parser and XSLT implementation.
> > - Change SVG building to use SAXSVGDocumentFactory. Downside: this only
> > helps with SVG and not with any other namespace.
> > - Look into the Batik source code if a defensive check could be added so
> > empty Strings are converted to null values. Downside: Is available only
> > after the next Batik release and it may not be the right thing to do.
> > But I can still let them know about the issue.
> > - Create our own DOMBuilder. Downside: Code duplication, a lot of work,
> > potential bugs etc.
> >
> > Woa, a lot of text. My opinion: Mark this as "WON'T FIX" and rely on
> > replacing the buggy Xalan implementation as described earlier.
> >
> > [1] http://svn.apache.org/viewcvs.cgi?rev=334122&view=rev
> > [2]
> > http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-745549614
> > (see setAttributeNS)
> > [3] http://svn.apache.org/viewcvs.cgi?rev=336570&view=rev
> >
> > On 24.02.2006 10:02:24 Jeremias Maerki wrote:
> >
> >>Jason, after some tests I found out that this only fails with JDK 1.4.2
> >>without any overridden endorsed libraries [1] in place. It doesn't
> >>happen with an unpatched JDK 1.5.0_03, for example. I always use the
> >>latest Xerces and Xalan version which is why I didn't stumble upon the
> >>problem when I changed the way SVG is parsed in FOP Trunk recently. I'll
> >>try to track down the problem because this is still a little suspicious.
> >>But since the XML parser and XSLT implementation shipped with JDK 1.4
> >>are known to have issues I suggest you replace those in your JDK
> >>installation. Despite the problem at hand it is (IMO) generally a good
> >>idea to do.
> >>
> >>To replace the JARs:
> >>Create a directory called "endorsed" under the jre/lib directory of your
> >>JDK installation (applies to all versions >= 1.4.0) and put all the
> >>XML-related JARs shipped with FOP in there, i.e. "xml-apis", "xercesImpl",
> >>"xalan" and "serializer".
> >>
> >>[1] http://java.sun.com/j2se/1.4.2/docs/guide/standards/
> >>
> >>On 23.02.2006 09:17:23 Jason R Briggs wrote:
> >>
> >>>Anyone else experiencing problems with SVG with the trunk version of fop?
> >>>
> >>>For example, the FO bel
