Hi Dom,<div><br></div><div>You can probably tell me :) I&#39;m not claiming to be a poppler genius. Please do elaborate on the suitability the CairoOutputDevice to generate an SVG (remembering that SVGs are favoured for their vector ability for text, lines and filled shapes).<br>
<br>Thanks, Todd.<br><br><div class="gmail_quote">On 4 November 2011 22:55, Dominic Lachowicz <span dir="ltr">&lt;<a href="mailto:domlachowicz@gmail.com">domlachowicz@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Just out of curiosity, how would the proposed SVGOutputDevice differ<br>
from using (say) the existing CairoOutputDevice that was configured to<br>
write to SVG? That can already be accomplished today.<br>
<br>
Thanks,<br>
Dom<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 4, 2011 at 7:38 AM, Todd Hubers &lt;<a href="mailto:todd.hubers@alivate.com.au">todd.hubers@alivate.com.au</a>&gt; wrote:<br>
&gt; Alec, I&#39;m quite sold on the SVG idea. It is self contained and can even work<br>
&gt; outside the browser.<br>
&gt; Josh, it would seem that the HTMLOutputDevice is the better candidate for<br>
&gt; SVG. HTML would be a good interim solution as well, however with SVG,<br>
&gt; everything is packaged into a single file as a package. With HTML the<br>
&gt; browser is making repeated calls back to the web server (for image<br>
&gt; resources), but with SVG it&#39;s naturally all together. You can also achieve<br>
&gt; effects like gradients in SVG quite easily and is better supported by older<br>
&gt; browsers than alternative approaches to getting PDF into the browser.<br>
&gt; I am interested in seeing the latest version of the HTML solution. I may<br>
&gt; attempt some preliminary SVG rendering.<br>
&gt;<br>
&gt; Back on the topic of &quot;Data&quot; output device. I&#39;m already using XML for RTF<br>
&gt; output (I&#39;m doing this in my language of choice - C# though so it&#39;s not an<br>
&gt; easy task to contribute this back to poppler). It&#39;s true that direct<br>
&gt; implementation of device drivers are more efficient, however XML or the like<br>
&gt; do provide a convenient interface very accessible for many programming<br>
&gt; languages. I would not expect such a &quot;data&quot; output device to be used by PDF<br>
&gt; viewing applications. However it would be good for all other purposes, where<br>
&gt; such implementations are usually performed in batch processes and the extra<br>
&gt; processing in the presence of multi-threading is readily accepted in return<br>
&gt; for flexibility - that is, a larger community can make use of poppler.<br>
&gt; Cheers,<br>
&gt; Todd<br>
&gt; On 4 November 2011 17:24, Josh Richardson &lt;<a href="mailto:jric@chegg.com">jric@chegg.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi Todd,<br>
&gt;&gt; Some of us who are working on pdftohtml utility have had similar thoughts.<br>
&gt;&gt;  It&#39;s on my wish list to completely remove the need for a poppler output<br>
&gt;&gt; device by utilizing the SVG toolset available in modern browsers.  In any<br>
&gt;&gt; case, we are achieving high accuracy on Gecko and Webkit browsers with the<br>
&gt;&gt; current version (not merged into the Poppler main repo yet, but I can send<br>
&gt;&gt; you an invite for a git repo that Alec Taylor made, which has all those<br>
&gt;&gt; latest changes.)  I think it might meet your needs as-is, or with some<br>
&gt;&gt; tweaks to make it work better on other browsers.<br>
&gt;&gt; We are currently extracting the text and fonts for the browser to render<br>
&gt;&gt; directly, but still must rely on Splash, Cairo, etc. to rasterize other<br>
&gt;&gt; graphic operations.  With the way we&#39;ve done it, we have an easy path to<br>
&gt;&gt; change over to SVG, one graphic operation at a time, if you&#39;d be interested<br>
&gt;&gt; in doing that.<br>
&gt;&gt; The idea of a separate &quot;data&quot; device is interesting, but I don&#39;t think<br>
&gt;&gt; it&#39;s the right way to go.  In effect, you are talking about changing the PDF<br>
&gt;&gt; data to XML, and from there to other formats.  I can appreciate the<br>
&gt;&gt; sentiment, since PDF is such a difficult format to work with, but adding a<br>
&gt;&gt; layer of abstraction is just going to make things more complex, error-prone,<br>
&gt;&gt; and slow.  To note, the current version of pdftohtml creates a valid<br>
&gt;&gt; XML-compliant HTML format — actually there&#39;s a small bug, but you probably<br>
&gt;&gt; get the point.  You can always use the XML-compliant HTML as your<br>
&gt;&gt; easier-to-digest &quot;data&quot; format, which also allows us to represent more<br>
&gt;&gt; semantics than are available in the original PDF document, and you can<br>
&gt;&gt; always extend it with whatever XML tags you need.  For example, I extended<br>
&gt;&gt; it with an attribute describing bounding boxes for all of the text spans.<br>
&gt;&gt;  Let me know if you want the repo invite.<br>
&gt;&gt; Best, --josh<br>
&gt;&gt; From: Todd Hubers &lt;<a href="mailto:todd.hubers@alivate.com.au">todd.hubers@alivate.com.au</a>&gt;<br>
&gt;&gt; Date: Thu, 3 Nov 2011 18:13:52 -0700<br>
&gt;&gt; To: &quot;<a href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a>&quot; &lt;<a href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a>&gt;<br>
&gt;&gt; Subject: [poppler] Poppler - SVG Device<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m currently using Poppler for Text extraction and using GhostScript for<br>
&gt;&gt; PDF to Image functionality, all for viewing PDFs online without requiring a<br>
&gt;&gt; PDF plugin in the browser.<br>
&gt;&gt;<br>
&gt;&gt; I noticed Mozilla was working on an interesting project, PDF.js<br>
&gt;&gt; [<a href="https://wiki.mozilla.org/PDF.js" target="_blank">https://wiki.mozilla.org/PDF.js</a>]. It loads PDF files with pure Javascript<br>
&gt;&gt; (on a HTML5 compatible browser - probably needs canvas).<br>
&gt;&gt;<br>
&gt;&gt; This is an opportunity for poppler to steam ahead and get some headline<br>
&gt;&gt; grabbing exposure. The SVG format is well supported by browsers. PDFs are<br>
&gt;&gt; portable across systems, however SVGs are very portable (and fast) across<br>
&gt;&gt; the web.<br>
&gt;&gt;<br>
&gt;&gt; I propose the building of an SVG Device - PDF to SVG. I am currently<br>
&gt;&gt; considering using PDF to XML, to then perform XML to SVG. Given the status<br>
&gt;&gt; quo, I believe it&#39;s time for PDF to SVG.<br>
&gt;&gt;<br>
&gt;&gt; I see SVG as a very efficient and therefore powerful web format, I hope<br>
&gt;&gt; others in the poppler community will see the potential as I do.<br>
&gt;&gt;<br>
&gt;&gt; Thanks,<br>
&gt;&gt;<br>
&gt;&gt; Todd Hubers (BBIT Hons)<br>
&gt;&gt; Alivate<br>
&gt;&gt;<br>
&gt;&gt; PS. Perhaps we could then have PDF&gt;Cairo, PDF&gt;SVG, and then tools for<br>
&gt;&gt; SVG&gt;XML, SVG&gt;HTML, SVG&gt;Text. In any case it would be good to have simply one<br>
&gt;&gt; direct rendering device and one &quot;data&quot; device.<br>
&gt;<br>
&gt;<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; poppler mailing list<br>
&gt; <a href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a><br>
&gt; <a href="http://lists.freedesktop.org/mailman/listinfo/poppler" target="_blank">http://lists.freedesktop.org/mailman/listinfo/poppler</a><br>
&gt;<br>
&gt;<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
&quot;I like to pay taxes. With them, I buy civilization.&quot; --  Oliver Wendell Holmes<br>
</font></span></blockquote></div><br></div>