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