search

taskjuggler / TaskJuggler

TaskJuggler - Project Management beyond Gantt chart drawing
http://www.taskjuggler.org
GNU General Public License v2.0
727 stars 168 forks source link

Export to SVG #98

Open r3n4ud opened 11 years ago

r3n4ud commented 11 years ago

A great feature will be to implement an "export to svg" or "svgreport" feature for diagrams. I'll be happy to help on this (done some svg-related work in the past). I can parse the code but some core team member could help on this to evaluate the feasibility and give some details on the actual diagrams production process.

This feature will be really usefull for non-connected / documentation usage, e.g. pdf document production (html to pdf conversion doesn't seem to be a good solution for me and svg to pdf conversion works relatively well if you know what you are doing). svg export seems the best option for vector-maniacs like me since we could post-edit the svg for document inclusion at an intermediate step of the whole document production process.

scrapper commented 11 years ago

TJ already uses SVG for some report elements. But most of the reports are still HTML to make use of the rendering capabilities of the browser. If you want to have all the reports available in pure SVG you would have to add the table and text rendering to TJ. That's A LOT of work. Since some programs like LibreOffice can embed HTML pages, this may not be worth the effort.

r3n4ud commented 11 years ago

I have browsed the code and figured out that indeed SVG is already used for some reports. I agree there is a fair amount of work to be done to implement a new backend like SVG (could be TikZ/pgf or Metapost) but you can't compare LibreOffice-like apps to LaTeX / ConTeXt...

r3n4ud commented 11 years ago

How about a "backend-as-a-plugin" approach to the issue? Divide and conquer may prove successfull in the long run.

r3n4ud commented 11 years ago

I'm curious: why implement XMLElement and XMLDocument and not use nokogiri for example?

scrapper commented 11 years ago

nokogiri is quite a heavy dependency. It may have caused pain on Windows and MacOS. I only need a small fraction of it and I did not like the API too much.

The plug-in would need to have full access to the internal data model to be flexible enough. I don't want to expose those APIs. For out of tree report generators, reading an output format and then converting it into the desired format is probably the better approach.

r3n4ud commented 11 years ago

OK, it seems to me that a new output format is needed for out-of-tree processing. Am I right? Maybe we should discuss this on the mailing list...

scrapper commented 11 years ago

There was some discussion regarding JSON output. I'm not sure that anybody is working on it though.

r3n4ud commented 11 years ago

Where to?

jwhendy commented 11 years ago

For what it's worth, I recently printed to PDF and used pdf2svg to successfully convert it. Works great in a browser, though the file size was a bit large (1.2MB), so I found the page load a bit slow when I uploaded it to an IBM Connections wiki at work. Definitely a workaround, but wanted to mention it if anyone following this needed this immediately.

r3n4ud commented 11 years ago

@jwhendy Thanks for sharing this. The best I have achieved is to hack the html report (sed is your friend) and apply a wkhtmltopdf conversion to get a decent PDF for direct inclusion in a ConTeXt document… Not optimal but best than nothing…

matthiasbeyer commented 7 years ago

I'd like to see SVG export as well, because embedding a HTML page into my thesis work (latex) is simply not possible. :smile: Having an SVG would be a great idea!