Topics

Trouble using SVGs with Oxygen #SVG #PDF

Matt Lorenzi
 

Is anyone else having trouble using SVGs in Oxygen for PDF output? 
No matter how I save-out my SVG I get weird results in Oxygen.

Either it imposes a large white area around the image and then it renders it super small on output.

I know not all SVGs are created equally. Some graphics programs build in an artboard dimension, others do not.
I know it's super popular to use SVGs, but frankly I hate them. There is zero guarantee on how they will render on different outputs/browsers.
I am very tempted to keep a working .AI file and save out all graphics as .PNG or .JPG

Eric Sirois
 

Hi Matt, 

Not sure what PDF formatter you're are using, but make sure the SVG has @width and @height defined on the root element.  If the size is only defined in the viewbox, then Euclid will just apply 400 x 400 as the default resolution for the image in your PDF.  We have a number of clients using SVG with FOP and AH as the PDF formatter.  For browsers, the SVG file must have the .svg extension otherwise the browser will not render them.

Eric

On Wednesday, January 22, 2020, 01:58:50 p.m. EST, Matt Lorenzi via Groups.Io <mjlorenzi@...> wrote:


Is anyone else having trouble using SVGs in Oxygen for PDF output? 
No matter how I save-out my SVG I get weird results in Oxygen.

Either it imposes a large white area around the image and then it renders it super small on output.

I know not all SVGs are created equally. Some graphics programs build in an artboard dimension, others do not.
I know it's super popular to use SVGs, but frankly I hate them. There is zero guarantee on how they will render on different outputs/browsers.
I am very tempted to keep a working .AI file and save out all graphics as .PNG or .JPG

Matt Lorenzi
 

Hi Eric,

Very good to know about the @width and @height in the root. From Adobe Illustrator, this is either included or note included depending if "Responsible" is checked or not.
So, if I uncheck this option, I get width/height values, which presumably is good; however, will these SVGs still behave responsively if used for WebHelp Responsive output? 

Largly doing PDF at present, but the goal is to build robust DITA that can be used in WebHelp in the near future.

Thanks!
Matt

Eric Sirois
 

Hi Matt,

Yes, we have clients that use SVG for their PDFs and Webhelp.  One client has a slightly different version of SVG for the web, then PDF.  I believe the size is slightly different to optimize viewing of the images between the two output formats.  Minus the placement (inline vs break) it should be fine in a web browser, at least for Firefox, Chrome. and Edge.  Not sure about IE11 though. 

Eric

On Wednesday, January 22, 2020, 02:42:42 p.m. EST, Matt Lorenzi via Groups.Io <mjlorenzi@...> wrote:


Hi Eric,

Very good to know about the @width and @height in the root. From Adobe Illustrator, this is either included or note included depending if "Responsible" is checked or not.
So, if I uncheck this option, I get width/height values, which presumably is good; however, will these SVGs still behave responsively if used for WebHelp Responsive output? 

Largly doing PDF at present, but the goal is to build robust DITA that can be used in WebHelp in the near future.

Thanks!
Matt

Ozana Dragomir
 

Hi,

We gave up on trying to use SVG for PDF output. Not as much because of size, but text not being displayed in the right place and so on - Apache FOP is not very good with SVG.
We converted all SVGs to PDF using inkscape from the command line and use the PDF images (which are still in vector format) for PDF output and SVG images for HTML/WebHelp. We use keys to include images in topics. There is one map with keys to PDF images and another map with the same keys pointing to the SVG images and we select which map to include based on the deliveryTarget attribute.

Yes, this is extra work and you have to remember to update the PDF image everytime you update the SVG image and so on, but it's the best solution we've found so far.

I hope that makes sense.

Regards,
Ozana

Wayne Brissette
 

Ozana Dragomir wrote on 2020-01-23 04:55:
Hi,

We gave up on trying to use SVG for PDF output. Not as much because of size, but text not being displayed in the right place and so on - Apache FOP is not very good with SVG.
I'll throw this out there as well because I've spent a lot of time recently tracking down SVG issues on our end. The Apache FOP is using the Batik library, which follows the W3 guidelines. The biggest issues I've seen are that not every drawing tool out there is doing a great job at producing SVGs that comply with the W3 guidelines. Granted the SVG spec itself needs tightening up and most vendors are doing OK there, but one tool (which I won't shame here) which is fairly common in use, creates horrible SVGs. We've written custom scripts to go in an 'fix' these so Antenna House handled them properly. Now that we're moving some production to the Apache FOP (and not doing any cleanup on them), our Information Developers are complaining about how the new process isn't handling said SVGs correctly. Basically we need to go in and re-implement the cleanup and corrections.

Because we automate a lot of diagrams from code these days, I've not looked into converting to PDF for some things. But this thread has given me some additional thoughts on maybe doing that.

-Wayne

Matt Lorenzi
 

I think the SVG vendor you won't mention is the same "freeware" program used by our software team. The issue we are having is with <flowRoot> which was something developed for SVG 1.2 and never fully adopted/implemented. So this vendor played a bit loose in "supporting" a feature that was not yet ready. The solution for me is to not use this program to begin with, but short of that, don't use the <flowRoot> tag - which essentially allows text to flow within a text box. 

I don't blame Oxygen for this one, however do find it funny that the ever-clunky Adobe FrameMaker was able to process these SVG files without issue. Perhaps they use a different SVG processing engine?

Wayne Brissette
 

Matt Lorenzi via Groups.Io wrote on 2020-01-23 11:13:
I think the SVG vendor you won't mention is the same "freeware" program used by our software team. The issue we are having is with <flowRoot> which was something developed for SVG 1.2 and never fully adopted/implemented. So this vendor played a bit loose in "supporting" a feature that was not yet ready. The solution for me is to not use this program to begin with, but short of that, don't use the <flowRoot> tag - which essentially allows text to flow within a text box.
Actually, No... But you've highlighted the biggest SVG challenge. Every vendor does things differently.

-Wayne

Matt Lorenzi
 

I get a fatal error message on publishing my Ditamap because the FOP encountered an element <flowRoot>. I went through all my topics looking for image error messages, but could find none. Not saying there is not an image in there somewhere that has <flowRoot> in it.

I don't think the build log will tell me exactly where it encountered the error. Not sure what is left for me to do other than open all of my SVG files in a text editor and search for <flowRoot>. 

Damn Inkscape!

Wayne Brissette
 



Matt Lorenzi via Groups.Io wrote on 2020-01-23 18:41:

I don't think the build log will tell me exactly where it encountered the error. Not sure what is left for me to do other than open all of my SVG files in a text editor and search for <flowRoot>. 

Just use grep. This is how I find errors in SVGs all the time. I also wonder if folks are saving out in the Inkscape SVG format or standard SVG format. We've encountered errors using their SVG format, but almost none using the standard SVG export from Inkscape.

-Wayne

Radu Coravu
 

Hi Matt,

In the Oxygen main menu "Find" there is a "Find/Replace in Files" action which you can use to search for content in all files in a certain path.

Regards,
Radu

Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

On 1/24/2020 2:41 AM, Matt Lorenzi via Groups.Io wrote:
I get a fatal error message on publishing my Ditamap because the FOP encountered an element <flowRoot>. I went through all my topics looking for image error messages, but could find none. Not saying there is not an image in there somewhere that has <flowRoot> in it.
I don't think the build log will tell me exactly where it encountered the error. Not sure what is left for me to do other than open all of my SVG files in a text editor and search for <flowRoot>.
Damn Inkscape!

Radu Coravu
 

Hi Matt,

Oxygen is using the Apache Batik SVG processing engine and probably Frame uses something else.

Regards,
Radu

Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

On 1/23/2020 7:13 PM, Matt Lorenzi via Groups.Io wrote:
I think the SVG vendor you won't mention is the same "freeware" program used by our software team. The issue we are having is with <flowRoot> which was something developed for SVG 1.2 and never fully adopted/implemented. So this vendor played a bit loose in "supporting" a feature that was not yet ready. The solution for me is to not use this program to begin with, but short of that, don't use the <flowRoot> tag - which essentially allows text to flow within a text box.
I don't blame Oxygen for this one, however do find it funny that the ever-clunky Adobe FrameMaker was able to process these SVG files without issue. Perhaps they use a different SVG processing engine?

Matt Lorenzi
 

The Inkscape SVG issue is minor compared to other issues with Frame. I'm much happier in the Oxygen world.