File size when including SVGs
Hi all, I'm currently using FOP 0.93, and I've just started looking at using SVG images in the rendered PDFs. One thing that I have noticed is that the image size of the resulting PDF grows considerably. It would appear that if I import an SVG multiple times, the resulting PDF includes a new instance of the image. If I have a 20k SVG displayed in the header of a 20 page document, then it adds 400k to the PDF (before compression). Is this correct? If so, is there a way around it? My plan is to use a small number of SVGs a large number of times, so being able to embed an image once, and simply reference it each time it is used in the PDF would greatly reduce space. If this isn't the case, then I obviously need to try and figure out why my PDFs seem to grow considerably if I repeat the same image. I'm mostly importing SVGs as background images, but some are inserted with Thanks. -- Be seeing you, http://www.glendale.org.uk Sam.Mail/IM (Jabber): [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Referenced pattern not applied when PDF is encrypted
On Sep 3, 2008, at 14:02, Lea Thurman wrote: Hi We am more than happy to spend time on this and hopefully fix and submit it back. However having never filed a defect or committed to FOP before is there are starter for 10 that tells me about servers/repositories/ locations etc and the general process to be followed. If you mean you potentially will do some development on the FOP codebase, and want to donate it back, then the main 'Development' page would be a good place to start: http://xmlgraphics.apache.org/fop/dev/index.html If OTOH, you simply want to log the issue, supply more info (and preferably some FO/SVG samples as well), then this is where you need to be: http://xmlgraphics.apache.org/fop/bugs.html Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error when using XSL with French Characters
On Sep 3, 2008, at 18:35, Steffanina, Jeff wrote: Hi Jeff There is always one MORE option to consider!! What would you suggest as the best way to handle this? I think I'd opt for using (N)umeric (C)haracter (R)eferences. Reasoning would be that if one changes the BASIC code to emit the sequence 'è', this will never, ever have to be changed (unless Unicode would somehow decide on altering the codepoints). You can change the encoding in the XML header all you want, NCRs will always work. On the other hand, if you have a LOT of those characters, using NCRs could make your XML a bit bulky (instead of 1 byte/character, you actually generate 6-8 bytes to represent one character in the final result; the XML parser, instead of needing only one byte, has to parse all bytes from '&' up to and including ';'). The character code you mentioned earlier (130) is the decimal value for 'é' in ASCII, so if you're concerned with the size of the XML and do not want to generate 6 bytes for one character, try specifying "US- ASCII" as encoding for the source XML. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with inserting a PNG file
On 8/28/2008 9:34 AM, Jubal Kessler wrote: > Aug 28, 2008 6:20:05 AM org.apache.fop.fo.flow.ExternalGraphic bind > SEVERE: Image not available: No ImagePreloader found for As closure, it turns out I had been staring too long at the same XSL-FO template, and the problem was a simple error in external-graphics usage. My apologies to all, and thanks for the replies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error when using XSL with French Characters
There is always one MORE option to consider!! What would you suggest as the best way to handle this? Jeff -Original Message- From: Andreas Delmelle [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 12:32 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Error when using XSL with French Characters On Sep 3, 2008, at 15:05, Steffanina, Jeff wrote: Hi Jeff > fop-0.95 > I am running Redhat Linux 2.4.21-47.0.1. > > The letter I am referring to is: é è > I assume I am having problems with any French character that > includes a glyph. > > What are you using for > > I appreciate any suggestions. I have not had to deal with > international characters sets before. If all else fails, remember that XML *always* allows Numeric Character References, like or for a linefeed (values are always UTF-8 codepoints). In UTF-8, the respective character codes are: è -> è é -> é If you output those sequences in the BASIC module, then it should work, regardless of which encoding is specified in the XML header. HTH! Cheers Andreas - 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]
Re: Error when using XSL with French Characters
On Sep 3, 2008, at 15:05, Steffanina, Jeff wrote: Hi Jeff fop-0.95 I am running Redhat Linux 2.4.21-47.0.1. The letter I am referring to is: é è I assume I am having problems with any French character that includes a glyph. What are you using for I appreciate any suggestions. I have not had to deal with international characters sets before. If all else fails, remember that XML *always* allows Numeric Character References, like or for a linefeed (values are always UTF-8 codepoints). In UTF-8, the respective character codes are: è -> è é -> é If you output those sequences in the BASIC module, then it should work, regardless of which encoding is specified in the XML header. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error when using XSL with French Characters
Jean-Francois, On my Linux box I have this entry in: /etc/sysconfig/i18n LANG="en_US.iso885915" Jeff Steffanina FOSSE Development, Bethesda, MD (301)380-2047 [EMAIL PROTECTED] This communication contains information from Marriott International, Inc. that may be confidential. Except for personal use by the intended recipient, or as expressly authorized by the sender, any person who receives this information is prohibited from disclosing, copying, distributing, and/or using it. If you have received this communication in error, please immediately delete it and all copies, and promptly notify the sender. Nothing in this communication is intended as an electronic signature under applicable law. -Original Message- From: Jean-François El Fouly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 8:58 AM To: fop-users@xmlgraphics.apache.org Subject: Re: Error when using XSL with French Characters There are four kinds of accent current in French (é è ê ë) so you should be more precise. None of them can possibly correspond to CHR(130) neither in UTF-8 nor in ISO-8859-1 On what kind of system/platform/OS are you working ? Mentioning vi makes me guess it should be some kind of Unix but at the same time the encoding used makes this improbable... I guess more information is needed here. Steffanina, Jeff a écrit : > Manuel, > > We create the XML using a version of BASIC. To create this particular > character, we send CHR(130) to the XML. When I open the XML in "vi", > I see the proper FRENCH symbol. > > > > */Jeff /* > > > *From:* Manuel Mall [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, September 02, 2008 10:51 PM > *To:* 'fop-users@xmlgraphics.apache.org' > *Subject:* RE: Error when using XSL with French Characters > > I am suspicious that although you declare the XML file as being in > UTF-8 it actually isn't. How do you produce the XML file? > > > > Manuel > > > > > > *From:* Steffanina, Jeff [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, 3 September 2008 10:23 AM > *To:* fop-users@xmlgraphics.apache.org > *Subject:* Error when using XSL with French Characters > > > > > > My Friends, > Fop-0.95 My style sheet has been working perfectly. However, > the user submitted some text in French. In the text was a letter > "e" with an accent above it. > > That character caused the following error: > Invalid byte 1 of 1-byte UTF-8 sequence. > > My .xml looks fine. The "e" with the accent above it is perfect. > First line in my XML: > > > Here is the first line of my XSL: > > > I am confused over why the UTF-8 for the XML understands the > character but the UTF-8 in the XSL does not? > > I found an article that suggests that the problem would be solved > with: > > > Would this be a viable/recommended solution? Do you have a > better idea? > > > - 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]
RE: Error when using XSL with French Characters
Jean-Francois, fop-0.95 I am running Redhat Linux 2.4.21-47.0.1. The letter I am referring to is: é è I assume I am having problems with any French character that includes a glyph. What are you using for I appreciate any suggestions. I have not had to deal with international characters sets before. Thanks. Jeff -Original Message- From: Jean-François El Fouly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 8:58 AM To: fop-users@xmlgraphics.apache.org Subject: Re: Error when using XSL with French Characters There are four kinds of accent current in French (é è ê ë) so you should be more precise. None of them can possibly correspond to CHR(130) neither in UTF-8 nor in ISO-8859-1 On what kind of system/platform/OS are you working ? Mentioning vi makes me guess it should be some kind of Unix but at the same time the encoding used makes this improbable... I guess more information is needed here. Steffanina, Jeff a écrit : > Manuel, > > We create the XML using a version of BASIC. To create this particular > character, we send CHR(130) to the XML. When I open the XML in "vi", > I see the proper FRENCH symbol. > > > > */Jeff /* > > > *From:* Manuel Mall [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, September 02, 2008 10:51 PM > *To:* 'fop-users@xmlgraphics.apache.org' > *Subject:* RE: Error when using XSL with French Characters > > I am suspicious that although you declare the XML file as being in > UTF-8 it actually isn't. How do you produce the XML file? > > > > Manuel > > > > > > *From:* Steffanina, Jeff [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, 3 September 2008 10:23 AM > *To:* fop-users@xmlgraphics.apache.org > *Subject:* Error when using XSL with French Characters > > > > > > My Friends, > Fop-0.95 My style sheet has been working perfectly. However, > the user submitted some text in French. In the text was a letter > "e" with an accent above it. > > That character caused the following error: > Invalid byte 1 of 1-byte UTF-8 sequence. > > My .xml looks fine. The "e" with the accent above it is perfect. > First line in my XML: > > > Here is the first line of my XSL: > > > I am confused over why the UTF-8 for the XML understands the > character but the UTF-8 in the XSL does not? > > I found an article that suggests that the problem would be solved > with: > > > Would this be a viable/recommended solution? Do you have a > better idea? > > > - 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]
Re: Error when using XSL with French Characters
There are four kinds of accent current in French (é è ê ë) so you should be more precise. None of them can possibly correspond to CHR(130) neither in UTF-8 nor in ISO-8859-1 On what kind of system/platform/OS are you working ? Mentioning vi makes me guess it should be some kind of Unix but at the same time the encoding used makes this improbable... I guess more information is needed here. Steffanina, Jeff a écrit : Manuel, We create the XML using a version of BASIC. To create this particular character, we send CHR(130) to the XML. When I open the XML in "vi", I see the proper FRENCH symbol. */Jeff /* *From:* Manuel Mall [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, September 02, 2008 10:51 PM *To:* 'fop-users@xmlgraphics.apache.org' *Subject:* RE: Error when using XSL with French Characters I am suspicious that although you declare the XML file as being in UTF-8 it actually isn't. How do you produce the XML file? Manuel *From:* Steffanina, Jeff [mailto:[EMAIL PROTECTED] *Sent:* Wednesday, 3 September 2008 10:23 AM *To:* fop-users@xmlgraphics.apache.org *Subject:* Error when using XSL with French Characters My Friends, Fop-0.95 My style sheet has been working perfectly. However, the user submitted some text in French. In the text was a letter "e" with an accent above it. That character caused the following error: Invalid byte 1 of 1-byte UTF-8 sequence. My .xml looks fine. The "e" with the accent above it is perfect. First line in my XML: Here is the first line of my XSL: I am confused over why the UTF-8 for the XML understands the character but the UTF-8 in the XSL does not? I found an article that suggests that the problem would be solved with: Would this be a viable/recommended solution? Do you have a better idea? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error when using XSL with French Characters
Manuel, We create the XML using a version of BASIC. To create this particular character, we send CHR(130) to the XML. When I open the XML in "vi", I see the proper FRENCH symbol. Jeff From: Manuel Mall [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2008 10:51 PM To: 'fop-users@xmlgraphics.apache.org' Subject: RE: Error when using XSL with French Characters I am suspicious that although you declare the XML file as being in UTF-8 it actually isn't. How do you produce the XML file? Manuel From: Steffanina, Jeff [mailto:[EMAIL PROTECTED] Sent: Wednesday, 3 September 2008 10:23 AM To: fop-users@xmlgraphics.apache.org Subject: Error when using XSL with French Characters My Friends, Fop-0.95 My style sheet has been working perfectly. However, the user submitted some text in French. In the text was a letter "e" with an accent above it. That character caused the following error: Invalid byte 1 of 1-byte UTF-8 sequence. My .xml looks fine. The "e" with the accent above it is perfect. First line in my XML: Here is the first line of my XSL: I am confused over why the UTF-8 for the XML understands the character but the UTF-8 in the XSL does not? I found an article that suggests that the problem would be solved with: Would this be a viable/recommended solution? Do you have a better idea?
Re: Referenced pattern not applied when PDF is encrypted
Hi, We am more than happy to spend time on this and hopefully fix and submit it back. However having never filed a defect or committed to FOP before is there are starter for 10 that tells me about servers/repositories/locations etc and the general process to be followed. Many Thanks Lea. Jeremias Maerki-2 wrote: > > Please file a bug in Bugzilla for this and add all the information here > to the issue. Thanks. > > Encryption is always a bit tricky and our PDF library has still a few > messy parts which can lead to certain corner cases not to be handled > correctly when encryption is present. Someone will have to fix it. Not > sure if I'll have time and energy very soon. At least, with the Bugzilla > entry it won't get forgotten. > > On 28.08.2008 11:59:23 Lea Thurman wrote: >> >> Hi, >> >> We are using FOP.0.95Beta on XP Pro and Mac OS X 10.5 and have >> encountered >> the following problem when we encrypt our PDF's on both OS's. >> >> We are generating the following SVG and then using FOP to convert this >> into >> a PDF. The PDF is rendered correctly and the referenced pattern applied >> if >> we do not encrypt the PDF. As soon as we encrypt the PDF the pattern is >> not >> applied. In both cases the SVG is identical. >> >> >> > "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd";> >> >> >> > patternUnits="userSpaceOnUse"> >> > xlink:href="file:/tmp/A12/89.png"/> >> >> >> > y="1.0in" stroke="none"/> >> >> >> The code being used to encrypt the pdf is as follows: >> >> userAgent.getRendererOptions().put( >> "encryption-params", >>new PDFEncryptionParams(null, null, false, true, true, true) >> ); >> >> Apologies if this is overly wordy. I have tried to simplify the scenario >> as >> much as possible. >> >> Any help would be much appreciated. >> >> Regards >> Lea. >> >> -- >> View this message in context: >> http://www.nabble.com/Referenced-pattern-not-applied-when-PDF-is-encrypted-tp19197539p19197539.html >> Sent from the FOP - Users mailing list archive at Nabble.com. > > > > Jeremias Maerki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Referenced-pattern-not-applied-when-PDF-is-encrypted-tp19197539p19287849.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Links in SVGs included into PDFs
I have to call in sick today so this is my last message for now. Just to give you some feedback. BTW, I noticed this should move to fop-dev since we're discussion development. Please drop the fop-users CC in any follow-ups. On 03.09.2008 10:00:59 Stefan Bund wrote: > Jeremias Maerki <[EMAIL PROTECTED]> writes: > > It just occurred to me that as an alternative we could simply track all > > XSL-FO IDs unconditionally. > > That was, what I was thinking about. As a very first step, I want to > implement just the Renderer part: Resolve the internal id references > if and only if they have been registered with the IdTracker already. > > If I have that, the next step is to get the target id's into the > IdTracker and it has already occured to me, why not just add all > id's, if that is not, what is already done (from your comments, it's > not). > > > That would make scanning the SVG (or HTML or MathML) for links > > unnecessary. > > Exactly. That would need an extension of Image and so on. I had > thought of giving Image (or a baseclass) a list of resolvables and > subclassing Image with a special SVGImage which would then do the > parsing and store the created SVG DOM Tree to be reused at render > time. > > However, this seems to be FAR more complicated then just registering > all id's ... Yes, and I wouldn't have like a SVG-specific solution. > > The overhead is probably even smaller and could actually have > > additional side-benefits for certain special use cases. For example, > > we could have an event that notifies the FOP-User which ID has its > > first (and last) area on which page. The area tree (and AT XML) size > > would increase a bit but I don't think by much (String plus > > PageViewport reference per destination). > > Sounds reasonable :-) > > > On 03.09.2008 09:35:52 Jeremias Maerki wrote: > >> Hmm, you're right. This is more complicated that I thought. Getting the > >> actual position of a link destination on a page is easily done with > >> information from PDFRenderer. > > This is, where I am standing currently. My problem is getting exactly > that information. > > I can use PDFRenderer.getPDFGoToForID(targetID, pvKey), however, for > that I need to already know the pvKey. As far as I understand, I could > get that information form the IdTracker but after lot's of grepping > and reading through the source code I could not find a way to access > the AreaTreeManager from the PDFRenderer. > > So my question at the moment is: a) How do I get at the page viewport > key given an id or more specifically b) How do I access the > AreaTreeManager from PDFRenderer. I don't think you should access the AreaTreeManager. The renderers are designed to be passive. I believe the Renderer should be informed by the AreaTreeHandler about any IDs it's managing. Not the other way around. > >> Maybe that helps. I hope I didn't scare you too much. > > No, you have cleared up lots of points which I guessed but was way from > sure about. Cool. > I'd try to continue along the way assuming the register-all-id's stuff > could work. And even if that would NOT work (register-all-id's), I > think i would be MUCH farther ... as a last resort I can always hack > references into the surrounding code, if needed even using some xslt > to preprocess the fo+svg stuff (which is already generated from > docbook in my case so adding some more xslt is realtively straight > forward). Quite a hack and not a general solution but it could at > least work for the moment :-) and I'm at the point where I'd be > grateful for ANY working solution (I have not found ANY way to produce > a PDF file with embeded images containing links into the PDF ... that > is, using open source technology). > > Many thanks for all your insight. I feel, this could even lead > somewhere :-) Good luck! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Links in SVGs included into PDFs
Jeremias Maerki <[EMAIL PROTECTED]> writes: > It just occurred to me that as an alternative we could simply track all > XSL-FO IDs unconditionally. That was, what I was thinking about. As a very first step, I want to implement just the Renderer part: Resolve the internal id references if and only if they have been registered with the IdTracker already. If I have that, the next step is to get the target id's into the IdTracker and it has already occured to me, why not just add all id's, if that is not, what is already done (from your comments, it's not). > That would make scanning the SVG (or HTML or MathML) for links > unnecessary. Exactly. That would need an extension of Image and so on. I had thought of giving Image (or a baseclass) a list of resolvables and subclassing Image with a special SVGImage which would then do the parsing and store the created SVG DOM Tree to be reused at render time. However, this seems to be FAR more complicated then just registering all id's ... > The overhead is probably even smaller and could actually have > additional side-benefits for certain special use cases. For example, > we could have an event that notifies the FOP-User which ID has its > first (and last) area on which page. The area tree (and AT XML) size > would increase a bit but I don't think by much (String plus > PageViewport reference per destination). Sounds reasonable :-) > On 03.09.2008 09:35:52 Jeremias Maerki wrote: >> Hmm, you're right. This is more complicated that I thought. Getting the >> actual position of a link destination on a page is easily done with >> information from PDFRenderer. This is, where I am standing currently. My problem is getting exactly that information. I can use PDFRenderer.getPDFGoToForID(targetID, pvKey), however, for that I need to already know the pvKey. As far as I understand, I could get that information form the IdTracker but after lot's of grepping and reading through the source code I could not find a way to access the AreaTreeManager from the PDFRenderer. So my question at the moment is: a) How do I get at the page viewport key given an id or more specifically b) How do I access the AreaTreeManager from PDFRenderer. >> Maybe that helps. I hope I didn't scare you too much. No, you have cleared up lots of points which I guessed but was way from sure about. I'd try to continue along the way assuming the register-all-id's stuff could work. And even if that would NOT work (register-all-id's), I think i would be MUCH farther ... as a last resort I can always hack references into the surrounding code, if needed even using some xslt to preprocess the fo+svg stuff (which is already generated from docbook in my case so adding some more xslt is realtively straight forward). Quite a hack and not a general solution but it could at least work for the moment :-) and I'm at the point where I'd be grateful for ANY working solution (I have not found ANY way to produce a PDF file with embeded images containing links into the PDF ... that is, using open source technology). Many thanks for all your insight. I feel, this could even lead somewhere :-) stefan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Links in SVGs included into PDFs
It just occurred to me that as an alternative we could simply track all XSL-FO IDs unconditionally. That would make scanning the SVG (or HTML or MathML) for links unnecessary. The overhead is probably even smaller and could actually have additional side-benefits for certain special use cases. For example, we could have an event that notifies the FOP-User which ID has its first (and last) area on which page. The area tree (and AT XML) size would increase a bit but I don't think by much (String plus PageViewport reference per destination). On 03.09.2008 09:35:52 Jeremias Maerki wrote: > Hmm, you're right. This is more complicated that I thought. Getting the > actual position of a link destination on a page is easily done with > information from PDFRenderer. But to know the actual page of the link > destionation requires the registration of the ID as an item of interest > at layout time. For basic-link this is a single INTERNAL_DESTINATION > trait that is set on the area tree object, resolved by a LinkResolver. > For an SVG, however, only a single area is created and you might have > multiple links from the SVG into areas created from XSL-FO. This would > require something slightly different from a LinkResolver, plus you'd > need to scan the SVG at layout time for any links into XSL-FO so their > page number is resolved during layout. That needs some additional > infrastructure (both Java classes and area tree XML). This should > probably be done by extending Image and ForeignObject (in the area > package) from a common superclass which can take a list of link > destinations. The LinkResolver probably can't be used for this, but > fortunately, it's just a matter of creating another Resolvable and > making sure it is used. > > So in all, not trivial at all, but this could actually be used later > should anyone ever plug in (X)HTML support into FOP, too. Or JEuclid > could use something like that for XLinks in MathML back into XSL-FO. > > Maybe that helps. I hope I didn't scare you too much. > > On 02.09.2008 23:31:57 Stefan Bund wrote: > > Replying to my own post since I have gotten a little bit further. > > > > Implementing internal links seems to be more complicated than I had > > expected. As far as I understand, internal links are resolved within > > the area tree before the tree is rendered. An (external) SVG image > > resource howvever is only parsed at the render stage. > > > > However, I could get further if I could access the AreaTreeManager > > (and thereby its IdTracker) from the PDFANode. However, I could not > > find any way to get there (I have the PDFGraphics2D object and I can > > get the PDFDocument or RendererContext but I could not find a > > reference to the AreaTreeManager anywhere). > > > > I know, this is probably not the correct way to do this (I would need > > to somehow create a LinkResolver for every link in the SVG file while > > creating the area tree but at the moment that is way over my head). I > > hope, I can resolve the id's by just querying the IdTracker. This will > > possibly only work when the id is referenced from some other place, > > but it would be a start. > > > > Any pointer how to proceed? > > > > And maybe I got everything completely wrong. If so, could someone > > please set me right? > > > > stefan. > > Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Links in SVGs included into PDFs
Hmm, you're right. This is more complicated that I thought. Getting the actual position of a link destination on a page is easily done with information from PDFRenderer. But to know the actual page of the link destionation requires the registration of the ID as an item of interest at layout time. For basic-link this is a single INTERNAL_DESTINATION trait that is set on the area tree object, resolved by a LinkResolver. For an SVG, however, only a single area is created and you might have multiple links from the SVG into areas created from XSL-FO. This would require something slightly different from a LinkResolver, plus you'd need to scan the SVG at layout time for any links into XSL-FO so their page number is resolved during layout. That needs some additional infrastructure (both Java classes and area tree XML). This should probably be done by extending Image and ForeignObject (in the area package) from a common superclass which can take a list of link destinations. The LinkResolver probably can't be used for this, but fortunately, it's just a matter of creating another Resolvable and making sure it is used. So in all, not trivial at all, but this could actually be used later should anyone ever plug in (X)HTML support into FOP, too. Or JEuclid could use something like that for XLinks in MathML back into XSL-FO. Maybe that helps. I hope I didn't scare you too much. On 02.09.2008 23:31:57 Stefan Bund wrote: > Replying to my own post since I have gotten a little bit further. > > Implementing internal links seems to be more complicated than I had > expected. As far as I understand, internal links are resolved within > the area tree before the tree is rendered. An (external) SVG image > resource howvever is only parsed at the render stage. > > However, I could get further if I could access the AreaTreeManager > (and thereby its IdTracker) from the PDFANode. However, I could not > find any way to get there (I have the PDFGraphics2D object and I can > get the PDFDocument or RendererContext but I could not find a > reference to the AreaTreeManager anywhere). > > I know, this is probably not the correct way to do this (I would need > to somehow create a LinkResolver for every link in the SVG file while > creating the area tree but at the moment that is way over my head). I > hope, I can resolve the id's by just querying the IdTracker. This will > possibly only work when the id is referenced from some other place, > but it would be a start. > > Any pointer how to proceed? > > And maybe I got everything completely wrong. If so, could someone > please set me right? > > stefan. > Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
