• 1 Post
  • 8 Comments
Joined 3 years ago
cake
Cake day: June 27th, 2023

help-circle
  • The one thing holding me back from switching from Windows to Linux was the very poor PDF support in Linux. Every time I raised this several people told me I use PDF wrong. Others would tell me to use Inkscape, Draw, Okular etc.

    Office workers, publishers, academics and many more are expected to edit several PDFs every day. It may be simply crossing things out in a draft, adding/deleting/extracting/converting pages, OCRing or dewarping images. Telling colleagues, clients and line managers they shouldn’t do it is not an option. Adobe does all this and more very well. This workflow is so common and important in so many contexts, I am surprised it’s not a separate application in the LibreOffice suite. What is more surprising is some of the attitudes.

    I have now switched to Linux anyway, but I had to create scripts to do things with Ghostscript. Not very user-friendly and I wouldn’t recommend Linux to people who rely heavily on PDF handling.


  • Same situation here. For heavier editing I now use local Stirling PDF and BentoPDF. As I say above, both run in docker, but Stirling PDF also comes as Appimage. They are powerful but don’t feel like integrated applications.

    But there is a surprising gap in Linux for PDF editing. Available tools are like toys for the task or geared towards techies. I would expect a PDF reader/editor to be a separate application in the LibreOffice suite. (No, Draw or Inkscape won’t cut it, sorry)


  • I stopped recommending Master PDF Editor when I realised they were trying to lock me in with letting me know after the event that watermarks would be added.

    PDF4QT is aekward in many ways but the latest version has the best compression, even allowing you to select one-by-one which images will be compressed and how.

    Other options for editing are local Stirling PDF and BentoPDF. Both run in docker, but Stirling PDF also comes as Appimage. They are powerful but don’t feel like integrated applications.



  • The implication is that sending links to encrypted files with the decryption key added to the URL (eg Thunderbird Send, Mega etc) is not zero-trust. Decryption may take place locally and the key part of the URL may not be sent to the file hosting service, but when the recipient clicks on the link and is served one-off code by the web site, that code may be compromised.

    As we know, the best way to be sure is to do your own separate encryption but without secure-by-design most people will think you are very odd demanding that decryption is done separately and keys are shared through a different channel. Speaking from experience, no matter how much training they are given at work, most people, including HR, would rather you sent them sensitive documents (like passport scans) in the clear as email attachments or at least in a way that involves a single click (Wetransfer etc).




  • A policy I saw coming out of an NHS (UK) department mandated ‘human-in-the-loop’ which is essentially what the article mentions in the end. The risk is that over time clinicians may become complacent with ‘good enough’ and don’t bother to review thoroughly. And it may be easy to spot mistakes, but not necessarily omissions unless you keep your own notes. More so after a long session, although medical appointments are typically short and focused.

    On a positive note, in my experience clinicians using LLMs do indeed spend more time engaging with service users. In an ideal world, they would be given time to engage and take notes, but this is not going to happen.