7 ms·

Does anyone know of a tool that can do this for PDFs instead?

by newman314 2y ago

warkdarrior 2y ago
As soon as someone writes a Javascript interpreter in Wuffs..
- jchw 2y ago
  Do you ever need a JS interpreter to parse a PDF? That's horrifying. I understand PDF has a bunch of limbs, but I always assumed the JS stuff was at least separate from the parsing. (I am familiar with the PDF format at a lower level but I never touched any of the weird features.)
  - timschmidt 2y ago
    I wrote an SVG that's all javascript, no elements. All the graphics are generated dynamically at runtime by the javascript. It's SVG standards compliant, but only opens correctly in browsers, not in inkscape or other desktop publishing apps. I work a lot in OpenSCAD, and had a need to design some custom graph paper. So I found the subset of SVG which was similar to OpenSCAD. :)
    - jszymborski 2y ago
      Frankly, I wouldn't begrudge a website for not correctly parsing an svg I composed entirely with javascript. It's annoying you can't just "flatten" or "bake" such an svg like yours into one composed entirely of elements (unless one exists?)
      - csande17 2y ago
        Often you can open the SVG in a browser and then use the developer tools to copy out the resulting nodes as "flat" SVG source code. Chrome even includes a --dump-dom flag you can use to do this on the command line, although I haven't tested it with an SVG.
        jszymborski 2y ago
        Clever!
Joel_Mckay 2y ago
There are PDF readers that do not support the scripting format extensions. Note this does not prevent unscrupulous companies abusing dominant market positions to voluntarily embed machine and serial hash watermarks. To be clear: formats like pdf, ps, webp, svg, and tiff are so badly implemented in some ecosystems... they can't _ever_ be assumed safe input formats. Thus, at some point people need to spin up an actual VM to transcode a "web" version, and scrub each stage of the rendering pipeline like a virus or header injection is already present. "I never play where nice things are, and don't break things" (Eliza Mowry Blven, The Humanitarian Review, Volume 3, March, 1905) Cheers =3
- tialaramex 2y ago
  I worked with TIFF pretty extensively, it's a mess but I don't see why a WUFFS TIFF codec can't be fine. What makes you say you need "an actual VM to transcode" a TIFF ?
  - Joel_Mckay 2y ago
    The complex formats of tiff and tga specifications makes it nearly impossible to span all the edge-cases with unit-tests. A VM can be in a known-state snapshot, process pre/post signature logged/compared with a scripted debugger, and binary input/output stripped of non-compliant metadata/blobs at each stage of the pipeline if the process behaves as expected. I've yet to find a better method than Honeypots to sustainably mitigate the complex leaky dependency mess on traditional architectures. It has been my experience that "all software is terrible, but some of it is useful". It may just be my bias, but I see code smell getting worse in recent decades... Have a nice day, =3 https://www.youtube.com/watch?v=aCbfMkh940Q https://www.youtube.com/watch?v=aCbfMkh940Q
    - tialaramex 2y ago
      So, there's actually no particular reason and if somebody cares to write one then yup, TIFF codec in WUFFS would in fact be safer and faster than your uh, approach.
deleted 2y ago
[deleted]
ThePowerOfFuet 2y ago
https://dangerzone.rocks/ https://dangerzone.rocks/
trustno2 2y ago
pdfs are really really hard. the only viewer that parses them semi-correctly is ... Acrobat Reader. try to ever read any code for PDFs and see all the horrors. Google gave up and just bought the code from foxit.
- kjksf 2y ago
  Google was never trying to write PDF reader from scratch so they never "gave up". They just bought foxit code to save years of development when they wanted to ship PDF reader in Chrome. Your comment about "the only viewer that is semi-correct" is also wildly off the mark. Parsing correctly written PDF files is hard but multiple engines can do it correctly. Parsing real life PDFs is much harder then correctly implementing PDF spec because lots of PDFs are just broken. They generators create invalid PDF files and then PDF readers have to spend heroic efforts to somehow make sense of this brokenness. Adobe does it better than most because... well it would be embarrassing if they didn't. They invented the format, they make money from their tools, they were doing it the longest, they have the largest archive of broken PDFs for testing etc. It's hard to expect that e.g. an open-source project with one or two developers can match that. I work on SumatraPDF so I know.
  - trustno2 2y ago
    OK. In one of my previous jobs, I needed to auto-fill PDF forms on BE (among other things with PDFs), the only thing that worked reliably across PDFs was Acrobat. I did not try SummatraPDF. edit: it seems Summatra doesn't support PDF forms? Either AcroForms or XFA forms?

Does anyone know of a tool that can do this for PDFs instead?

warkdarrior 2y ago

As soon as someone writes a Javascript interpreter in Wuffs..

jchw 2y ago
Do you ever need a JS interpreter to parse a PDF? That's horrifying. I understand PDF has a bunch of limbs, but I always assumed the JS stuff was at least separate from the parsing. (I am familiar with the PDF format at a lower level but I never touched any of the weird features.)
- timschmidt 2y ago
  I wrote an SVG that's all javascript, no elements. All the graphics are generated dynamically at runtime by the javascript. It's SVG standards compliant, but only opens correctly in browsers, not in inkscape or other desktop publishing apps. I work a lot in OpenSCAD, and had a need to design some custom graph paper. So I found the subset of SVG which was similar to OpenSCAD. :)
  - jszymborski 2y ago
    Frankly, I wouldn't begrudge a website for not correctly parsing an svg I composed entirely with javascript. It's annoying you can't just "flatten" or "bake" such an svg like yours into one composed entirely of elements (unless one exists?)
    - csande17 2y ago
      Often you can open the SVG in a browser and then use the developer tools to copy out the resulting nodes as "flat" SVG source code. Chrome even includes a --dump-dom flag you can use to do this on the command line, although I haven't tested it with an SVG.
      - jszymborski 2y ago
        Clever!

Joel_Mckay 2y ago

There are PDF readers that do not support the scripting format extensions. Note this does not prevent unscrupulous companies abusing dominant market positions to voluntarily embed machine and serial hash watermarks. To be clear: formats like pdf, ps, webp, svg, and tiff are so badly implemented in some ecosystems... they can't _ever_ be assumed safe input formats. Thus, at some point people need to spin up an actual VM to transcode a "web" version, and scrub each stage of the rendering pipeline like a virus or header injection is already present. "I never play where nice things are, and don't break things" (Eliza Mowry Blven, The Humanitarian Review, Volume 3, March, 1905) Cheers =3

tialaramex 2y ago
I worked with TIFF pretty extensively, it's a mess but I don't see why a WUFFS TIFF codec can't be fine. What makes you say you need "an actual VM to transcode" a TIFF ?
- Joel_Mckay 2y ago
  The complex formats of tiff and tga specifications makes it nearly impossible to span all the edge-cases with unit-tests. A VM can be in a known-state snapshot, process pre/post signature logged/compared with a scripted debugger, and binary input/output stripped of non-compliant metadata/blobs at each stage of the pipeline if the process behaves as expected. I've yet to find a better method than Honeypots to sustainably mitigate the complex leaky dependency mess on traditional architectures. It has been my experience that "all software is terrible, but some of it is useful". It may just be my bias, but I see code smell getting worse in recent decades... Have a nice day, =3 https://www.youtube.com/watch?v=aCbfMkh940Q https://www.youtube.com/watch?v=aCbfMkh940Q
  - tialaramex 2y ago
    So, there's actually no particular reason and if somebody cares to write one then yup, TIFF codec in WUFFS would in fact be safer and faster than your uh, approach.

deleted 2y ago

[deleted]

ThePowerOfFuet 2y ago

https://dangerzone.rocks/ https://dangerzone.rocks/

trustno2 2y ago

pdfs are really really hard. the only viewer that parses them semi-correctly is ... Acrobat Reader. try to ever read any code for PDFs and see all the horrors. Google gave up and just bought the code from foxit.

kjksf 2y ago
Google was never trying to write PDF reader from scratch so they never "gave up". They just bought foxit code to save years of development when they wanted to ship PDF reader in Chrome. Your comment about "the only viewer that is semi-correct" is also wildly off the mark. Parsing correctly written PDF files is hard but multiple engines can do it correctly. Parsing real life PDFs is much harder then correctly implementing PDF spec because lots of PDFs are just broken. They generators create invalid PDF files and then PDF readers have to spend heroic efforts to somehow make sense of this brokenness. Adobe does it better than most because... well it would be embarrassing if they didn't. They invented the format, they make money from their tools, they were doing it the longest, they have the largest archive of broken PDFs for testing etc. It's hard to expect that e.g. an open-source project with one or two developers can match that. I work on SumatraPDF so I know.
- trustno2 2y ago
  OK. In one of my previous jobs, I needed to auto-fill PDF forms on BE (among other things with PDFs), the only thing that worked reliably across PDFs was Acrobat. I did not try SummatraPDF. edit: it seems Summatra doesn't support PDF forms? Either AcroForms or XFA forms?