Earlier quoted context omitted.
That doesn’t mean there wasn’t file corruption.
I never said anything about file corruption. You asked how I know FineReader worked properly, and I explained why the article showed it working properly, and that preview doesn't work properly anymore.
Preview in macOS Big Sur is destroying PDFs
181–190 of 326 posts
Re: Preview in macOS Big Sur is destroying PDFs
#182Earlier quoted context omitted.
Having vulnerabilities is never great. However, this is a separate issue from whether the PDF reader explicitly allows code execution or supports some of the more obscure PDF extensions, which is what the parent was talking about.
isnt including fonts basically code execution in and of itself?
Re: Preview in macOS Big Sur is destroying PDFs
#183Re: Preview in macOS Big Sur is destroying PDFs
#184Why anyone treats PDF as anything but a write-once format is beyond me. It's so finicky that I'm not shocked bugs like this happen. The only programs I'd be reasonable sure wouldn't screw it up are Acrobat itself, and pdflatex and friends. I think we need a multi-image container format. It could be something that's literally a bunch of jpgs/pngs/pick your poison in a tar container, and given a new extension. OSes wou…
There already exist formats as you describe, but regardless, a change of format wouldn't fix anything. The same problem would just surface there, as Preview and whatever add support for those formats, and include editing features. If you don't want to break something, just don't try to edit it. That can't be enforced anywhere but at the individual user level. Even proprietary formats in first-party software have this…
I've never wanted to edit a PDF, so personally I'd rather the feature was gated behind a menu option or something so you had to deliberately ask for it.
Re: Preview in macOS Big Sur is destroying PDFs
#185Earlier quoted context omitted.
> absolutely DO NOT WANT - is web page like format with auto-flowing text I would love it, though, if PDF included this as something that's always entirely optional. Sometimes I want to read something just as formatted. If my display is big enough, and the formatting has any importance, I probably want that. Other times, my screen is smaller (phone) or the wrong shape (small laptop), and I'd rather the text confirm t…
> I would love it, though, if PDF included this as something that's always entirely optional. To be fair that’s what they are working on, with Liquid Mode for PDFs in Adobe Reader. The plan is that it will automatically work for all PDFs using some sort of AI magic.
Re: Preview in macOS Big Sur is destroying PDFs
#186Why anyone treats PDF as anything but a write-once format is beyond me. It's so finicky that I'm not shocked bugs like this happen. The only programs I'd be reasonable sure wouldn't screw it up are Acrobat itself, and pdflatex and friends. I think we need a multi-image container format. It could be something that's literally a bunch of jpgs/pngs/pick your poison in a tar container, and given a new extension. OSes wou…
PDF is one of the best things IMO - it's like a docker container for documents. The way the original authors intended it to be, including fonts and all the things that go into making a document. For example, I personally like to purchase books that are in PDF format, not epub/mobi. I want to rely on professional typesetting from the publishers, not some front-end engineer's vision of what the ebook should look like a…
Sounds like you want the PDF/A standard for archiving: https://en.wikipedia.org/wiki/PDF/A
It forbids embedding audio and video and JavaScript, requires embedding all the fonts, forbids encryption and patent-encumbered compression. It's basically the PDF format with the most regrettable features stripped out.
Re: Preview in macOS Big Sur is destroying PDFs
#187Earlier quoted context omitted.
And yet PDF re-writing keeps getting screwed up. Probably because it really is a bad format for this, with the pages of docs notwithstanding.
I never saw these screw-ups in Acrobat, so maybe the problem is not the format, but Apple?
Re: Preview in macOS Big Sur is destroying PDFs
#188[1] PDF is one of the strangest file formats I've worked with. It is a bizarre mix of binary and text, and some of the other design decisions are also perplexing.
Re: Preview in macOS Big Sur is destroying PDFs
#189Earlier quoted context omitted.
So is there an active Preview corruption example that doesn't involve ABBYY? I've used FineReader before for a commercial effort, I do remember it being very finicky.
I personally don't use anything else, but when the problem first occured a few years ago, it was not limited to PDFs from ABBYY. (Which is not to say that it's purely Preview.app's fault. Maybe all of these PDFs were created in a bad way, would not surprise me at all. Could very well be that Preview.app is actually "improving" and fixing old bugs/cruft, breaking things that worked before but never should have in the…
Exactly this.
So the question is, whose responsibility is it? Apple’s to magically support the intersection of all the broken sofware?
You essentially have argued that ABBY is popular enough that Apple should have tested it.
Maybe it is popular, but the implication is that Apple would need to regression test against all this popular PDF generating software for any change to the preview engine, since they wouldn’t be able to know for sure what software’s PDFs would be broken by conforming changes.
What we know they did, was to make a copy of Big Sur available for ABBY to use to test their own software. That’s pretty standard practice in a case like this and is them behaving responsibly.
If Preview really was at fault, ABBY could have raised the issue with Apple, and or put a warning in their own software. If it’s that popular, you’d think they would have an incentive to do this.
What isn’t obvious is that Apple should somehow introduce workarounds every time a third party doesn’t fix a bug.
Re: Preview in macOS Big Sur is destroying PDFs
#190My guess is that the output PDF is still valid, but that an embedded (subset) font has had its `ToUnicode` map stripped, so that there's no link between the character codes used in the text elements and the "actual" characters they represent (there are also other ways this corruption could happen, but dropping or mangling the `ToUnicode` map seems like a likely cause).