I think there is some level of hardwiring limiting the palatability of sweetness, at least in some people.
Anecdotally, even as a kid, I found Skittles to be unpleasantly sweet. To this day, I avoid most sweet soda drinks and seldom drink even those I can tolerate.
It is not discipline for me. It is not even taste. It is tolerance.
Microsoft Word can do it, but you must _save_ the document as a PDF. I know this because I've done it dozens of times, as recently as a year ago.
Notably, you _can't_ use PDF printers to accomplish this. PDF printers reduce the document to only visual data, losing interactive features.
I know Word isn't part of your solution but maybe this distinction between saving the document as a PDF vs. running the document through a printer driver will be useful to bear in mind in your case.
But I also suspect that you might have succeeded in the past unknowingly. This is because many, _many_ PDF viewers do not support internal jump links. This is apparently too "advanced" a feature for most in-browser viewers, for example, including the built-ins.
If you aren't already doing it, always test whether features are working in Adobe Reader before checking with viewers which may have reduced featuresets.
Thanks a lot! I'm exporting HTML documents to PDF from the browser on a regular basis, and normal http links have never had any problem to work, while jump links have been impossible.
Processing everything through Word after export could maybe be an option. In my experience exporting from the browser have been the only option to get nice PDFs. Everything else I've tried have mangled the layout something terribly, and Open Source converters are all of low quality.
It could be that it is the PDF clients that refuses all jump links, but then the problem is unsolvable, since these PDFs have to work on normal consumer devices such as Android and iOS phones. Apart from the jump links, PDFs are a god-send, since they work well everywhere.
Even if you did get it working, there is a very good chance that only Adobe Reader/Acrobat would support it.
This severely limits valid use-cases because users have become acclimatized to relying on in-browser viewers embedded in a web app (e.g. that of Google Drive, OneDrive, Dropbox, HubSpot, etc.) or built into the browser itself. These almost always are highly minimalistic implementations.
For example, in a previous company, we wanted to provide our clients with a PDF guide which had in-document jump links (which, in the world of HTML, would be called "URI fragment links") and also a functional table-of-contents in the form of PDF "bookmarks."
But I ran into two major blockers:
First, Microsoft Word is almost the only non-Adobe product which is capable of producing such PDFs, and only when _saving_ as a PDF, not when _printing_ as a PDF (which reduces the document to little more than would be printed on a page).
Second, the only in-browser PDF viewer I could find which supports these features was, somewhat surprisingly, the one which is provided in WordPress. It supports both.
A similar story played out among mobile and desktop PDF viewers which weren't Adobe.
So for our beautiful, accessibility-compliant, featureful PDF, we had to provide very strict instructions on how to view it properly. When provided for viewing online, it _had_ to be hosted in a WordPress instance. And when offered for download, it _had_ to be accompanied by loud instructions explaining the situation and requiring users to install the free Adobe Reader.
You likely dodged a bullet by avoiding the use of any advanced PDF feature.
> Even if you did get it working, there is a very good chance that only Adobe Reader/Acrobat would support it.
I'm not sure about this. At least on Linux, where I just tested - I have in-document jump links working across Chromium, Firefox, Evince, Okular, and even KOReader. Tested on a random arxiv PDF[0]. Chromium and KOReader don't highlight links, but clicking them still works.
I didn't test on Linux, since we only permitted BYO Linux machines exceptionally.
And the PDF feature support landscape may have changed in the last year, since it was Q1 of last year (2022), I believe, when I last checked the in-browser PDF viewers in Google Drive, OneDrive, HubSpot, and Chrome for macOS and Windows. I suppose it might have been longer since I did the actual comparative testing.
> we wanted to provide our clients with a PDF guide
How often do you think they printed this guide, and of those instances, how often do you think they cared if the layout/pagination/etc. was identical to seeing it electronically? If that number is sufficiently low, I'd argue that the guide should've just been HTML.
I was told that we needed it (a computer requirements document) in PDF for legal reasons. I pushed back and legal confirmed that they did, in fact, need it to be in PDF format.
I suspect it had something to do with accreditation, accessibility, and/or student aid policy compliance, since this was a school.
But legal may also have found the relative transience of HTML documents to be a liability if a student threatened suit based on frequently changing policies, because I updated the requirements document twice yearly. PDFs made versioning very straightforward from a legal perspective, because the filename and download link always "needed" to be different between versions, without requiring dev work.
> Microsoft Word is almost the only non-Adobe product which is capable of producing such PDFs
LaTeX works great for links, automatic table of contents, references, and the rest. Basically just have the line `\usepackage{hyperref}` and include a `\tableofcontents` and you're set.
The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript.
The opening paren is simply relocated to the other side of the function name or keyword.
What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle](https://en.wikipedia.org/wiki/Mere-exposure_effect)).
I've never used a Lisp-family language, but I find the reaction against parentheses to be overblown.
The reading order of the code is also _consistent,_ rather than the frequent switching between infix notation, prefix notation, and postfix notation which we have to learn and parse in most languages outside the Lisp family. This is a benefit which deceptively looks like it is _more_ complicated, despite being simpler to parse visually (and otherwise). Another example of the familiarity principle at work.
The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript.
This tired trope needs to die. Yes, there are more parentheses, because lisp also uses parentheses where other languages use [] or {} or ;.
The real thing is that people from C-like languages are used to seeing different block markers for different constructs. It takes effort to read Lisp coming from other languages, because those other languages have a richer symbol vocabulary. Learning to read code without those symbols is like reading English where all punctuation has been replaced with a single space. Sure you ll get there eventually but it s a very cheap straw man argument to pretend that the only complaint people have about Lisps is the positioning of the parentheses.
Not a lisp apologist haha, but I think Clojure tries to use fewer smooth parens “()” in general. Square parens “[]” and curly parens “{}” are used to help with things like variable declarations and stuff like data structures.
I recently started using Clojure and I’ve used languages like C#, JavaScript, and Python a lot. My two cents is that a Clojure-like language should try to embrace the aesthetics of a white-space language like Python, but use the parens as clues for scopes or blocks. So much could be done with formatting rules that just make parens easier to scan without some extra IDE highlighting or something.
The best part of parens is that you can try to pick a consistent format, but ya know that sometimes doesn’t happen because everybody likes to use parens differently lol.
There are strictly more parentheses since other languages also use [] and {} (and <>) instead for different things. Or even ; or whitespace. Ignoring the majority of available brace types is just stupid if you ask me. The parentheses being at the wrong positions is something I can deal with (still no fan of RPN, but w/e), but intentionally crippling syntax that could help is just not a good idea. Syntax is your friend, use it.
Janet also uses [] and {}, and there is a reason people like the really consistent syntax. For me that reason is blind aesthetics, but I swear to you I sincerely find lisp code easier to read than non-lisp code. It's not "intentionally crippling syntax" it's a genuine difference in taste.
> Normal purposeful speech makes different opinions closer, while speech under the feedback of the like button makes similar opinions even closer and different opinions further apart.
But there is another aspect to the complexities here.
Years ago, I started thinking of the LIKE/UPVOTE button as an "increase visibility" button.
I don't upvote just because I like it (humor perhaps being an exception).
Often, I'm not upvoting just the comments I like: I'm upvoting the whole containing _thread_, including the conflicting views if they seem to have been made in good faith.
Because when good quality discourse takes place, I want the whole instance to be seen.
In these cases, the intended audience of my upvotes is most immediately the algorithm (in a way), rather than human viewers.
Sometimes I've found myself wishing my upvotes could be made invisible to humans since I know many of them will interpret my upvote differently than intended. There is no nuance.
It gets me wondering how feedback mechanisms might be diversified to add nuance back into these systems (while still moderating complexity).
Emoticons (as on Slack) do add nuance, but every emoticon pack I've seen lacks nuance most in neutral and critical responses.
Of course, no technology we have now can compare with verbal discourse for nuance. But you and I are more likely to be able to influence feedback features on social media than to succeed in eliminating them.
> Years ago, I started thinking of the LIKE/UPVOTE button as an "increase visibility" button.
I think Mastodon tries to make that distinction with like vs boost. Boost seems to be about making a post more visible ("hey look at this!") and like is more about "thanks for posting". At least on the server I use.
I still make it a point to disable AutoPlay and AutoRun on every PC I possess.
No, operating system, thou shalt not be permitted to seek and run executable code automatically on every connected storage media. I thankest thou most assuredly.
This might be a function of how passively many people read, though – particularly as compared with the highly interactive posture of speech.
There are reading strategies which we can employ to engage the brain quite effectively.
Plus, writing is immediately replayable. Some would rather abuse this than rely on a more holistic reading strategy, but that doesn't discount the value of having a concrete, immediately-accessible, and yet persistent record of the communication.
Anecdotally, even as a kid, I found Skittles to be unpleasantly sweet. To this day, I avoid most sweet soda drinks and seldom drink even those I can tolerate.
It is not discipline for me. It is not even taste. It is tolerance.