Comment by throwanem | Hacker News Reader

Comment by throwanem | Hacker News Reader

I tossed a legal document at it which was recently of passing interest to me, and it looks like embedded fonts still need some work. I'm not inclined to share a test case from what I have, which relates to a change of name and in any case was not really prepared by anyone especially competent when it comes to PDFs and their content; I tested with the first, facially void, version I was given. But it is possible I'll find more use for this tool, and if a shareable test case does come along then I'll do so. (And heaven knows with this document format, embedded fonts are a total nightmare always, even somehow in programmatic authoring. I'm not criticizing!)

On a similar note, a downloadable (single-file HTML or so, although these days some kind of HTTP service is a practical necessity) version would be nice to have. Low pri even from my perspective; it isn't that I spend a lot of time in places with no cell signal, so much as just that tethering on an a la carte plan gets out of hand pretty quick, since applications aren't at all required to honor or even notice the existence of the "data saver" option.

This is really neat! Thanks for posting it, I've bookmarked it for later use in the "just need a quick tweak" kind of case. I'll look forward to seeing how it develops!

Fonts on the web are super hard. There’s hardly any useful browser APIs for the kind of typesetting you need for PDFs: itemization, character bounding boxes, font file sub setting, etc. To solve or properly, you need to include a lot of code, e.g. all of harfbuzz compiled to wasm.

Well, that's the thing. Web fonts are hard. PDF fonts are super hard. Both at once is...actually maybe not hideous these days. Oh, I would not wish the task of devising such an algorithm, but the subset of vector fonts supported in PDF and that in browsers aren't totally disjoint, I think.

Modern processors can handle the relevant conversion math without really waking from sleep, which will no doubt make it more frustrating when some W3C third party resource security model WG fistfight from 2013 makes it impossible to both construct and use a webfont on the client. (There may be some hideous blob URL magic, but those are length constrained so you could up in N subset nonce fonts bucketing M custom glyphs from the source document, with a hideously complex fifty-case rewrite for all the p90 ways of mapping fonts in PDF (or is that 90 cases and p50?) to render the document in the editor. And then have to handle the actual editing cases, like what happens when your subset nonce font of a subset embedded font doesn't map any character to the keycode you just saw, and you want to try to give the user something with metrics sorta matching what they wanted instead of Helvetica or Times New Roman out of a naïvely constructed fontset.

I may have worked with PDF in browsers one time too many, before. But the idea of using WASM to smuggle real tools into this impoverished environment actually makes a lot of sense to me...

Emedded fonts only embed the used characters, so if ypu want to change "John" to "Mary" and there is no capital "M" elsewhere in the doccument, you are out of luck. Can this be your problem?

The mapping is incorrectly decoded and applied such that many characters for which glyphs are embedded and applied do not show them. It's a pretty common style of PDF mojibake, I think, and sometimes appears also with badly subsetted webfonts or "icon font" abortions if you disable page fonts in your browser settings.

Thank you!

I'll take a look at improving rendering embedded font support. And that's a neat idea to be able to download it for offline, I'll give some thought to that. Appreciate your feedback!

FYI - using service workers would automatically make it work offline and possibly be easier than trying to bundle it into one HTML file.

Oh, that's an excellent point, especially since this is a perfect case for workers more broadly. I've had a bit of an app dev interregnum these last or postpandemic years; if service worker support has advanced that broadly, then that's wonderful news! Not especially surprising news, I suspect, but wonderful. Last I afforded close attention, the state of play for service workers in iOS Safari particularly was "don't bother."

Since I like an iPhone - or have thought at least they're least worst for 13 years and counting - you can probably imagine how this would have depressed my interest: Even though irrelevant here in that touchscreen PDF editing is an extremely hard problem and none I'd expect a solo dev to address, just knowing nothing I built with a worker I would myself be able to use, has made me not want to sink good time and effort into the topic at all. Best case that's all just wasted; worst case, it creates a dilemma I might not escape without a new regret.

The service worker functionality can be expressed as a PWA! Based on the comments I'm thinking of heading in that direction.

As far as touchscreen PDF editing, that is 100% doable and something I plan on adding soon. Touchevents are supported natively in the web

https://developer.mozilla.org/en-US/docs/Web/API/Touch_event...

You should make your app a PWA [1]

PWAs are basically "installable" pages which open in their own browser window and generally can work offline

[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

I love the idea of a downloadable version because I suspect there are a lot of business cases of

* Need to make a relatively narrow change to a PDF (add a line, reorder pages, concatenate two files)

* Adobe is $$$ and pretty much a subscription-only fiasco. Even the most trivial tasks are paywalled.

* Even if you're paying for Adobe at a corporate level, getting the IT clearance to get it installed might be more time sink than the actual task,

We have a server that had pdftk installed to generate some pre-filled documents and I ended up using that to concatenate two PDF files instead of fighting to get Real Acrobat.

Reply on news.ycombinator.com