The traceback is actually shown based on the last-thrown exception (that thrown from the finally in this example), but includes the previous "chained exceptions" and prints them first. From CPython docs [1]:
> When raising a new exception while another exception is already being handled, the new exception’s __context__ attribute is automatically set to the handled exception. An exception may be handled when an except or finally clause, or a with statement, is used. [...] The default traceback display code shows these chained exceptions in addition to the traceback for the exception itself. [...] In either case, the exception itself is always shown after any chained exceptions so that the final line of the traceback always shows the last exception that was raised.
So, in practice, you will see both tracebacks. However, if you, say, just catch the exception with a generic "except Exception" or whatever and log it without "__context__", you will miss the firstly thrown exception.
My version of Firefox (146.0 on Debian) has exactly this. If I select a sentence and right-click, I get the menu item "Translate selection to <LANGUAGE>". In the resulting box, I can change the language pair - but the defaults that I have seen were also reasonable.
The tokenization can represent uncommon words with multiple tokens. Inputting your example on https://platform.openai.com/tokenizer (GPT-4o) gives me (tokens separated by "|"):
It's kind of fun to compare this formulation with the seemingly contradictory official arXiv argument for submitting the TeX source [1]:
> 1. TeX has many advantages that make it ideal as a format for the archives: It is plain text, it is compact, it is freely available for all platforms, it produces extremely high-quality output, and it retains contextual information.
> 2. It is thus more likely to be a good source from which to generate newer formats, e.g., HTML, MathML, various ePub formats, etc. [...]
Not that I disagree with the effort and it surely is a unique challenge to, at scale, convert the Turing complete macro language TeX to something other than PDF. And, at the same time, the task would be monumentally more difficult if only the generated PDFs were available. So both are right at the same time.
Working with both at the same time makes their strengths and pitfalls shine. It's like that dual-boot computer where you're constantly in the wrong OS.
HTML has better separation of concerns than latex.
Latex does typesetting a lot better than html.
HTML layout can differ wildly in the same document.
Latex documents are easier to layout in the first place.
That would (mostly if not always) work in the sense of reproducing the layout of the pages, but would defeat the purpose of preserving the semantic information present in the TeX file (what is a heading, a reference and to what, a specific math environment, etc.) which is AFAIK already mostly dropped on conversion to PDF by the latex compiler.
Why have you failed though? Is the point to try to deceive people to think that XKCD actually published something else? Why not modify the xkcd one without hinding the fact that you modified it?
Usually, completing the domain name by adding the final period will do the job. Instead of entering myprinter into the address bar, try myprinter. so your DNS server doesn't try to resolve myprinter, myprinter.domain, myprinter.domain.tld, and whatever other search domains have been configured. A real, fully-qualified domain ends in a period, though most tools will happily let you avoid that final period.
Alternatively, .local domains will work for mDNS-capable devices (and non-mDNS-capable devices if you like to risk things breaking randomly), and the .internal TLD has been reserved so .internal domains should also work for local addresses.
This made me think of Microsoft's MarkItDown tool/library [1] which seems to have quite the overlap in supported file formats [2,3] and conversion options [4]. I couldn't find any reference to the library on the website, so it may be useful to know about.
pdfjam [1] uses a LaTeX package under the hood, is included with the TeX Live distribution and acts as a wrapper for a LaTeX package. With this, I believe your example would be:
The traceback is actually shown based on the last-thrown exception (that thrown from the finally in this example), but includes the previous "chained exceptions" and prints them first. From CPython docs [1]:
> When raising a new exception while another exception is already being handled, the new exception’s __context__ attribute is automatically set to the handled exception. An exception may be handled when an except or finally clause, or a with statement, is used. [...] The default traceback display code shows these chained exceptions in addition to the traceback for the exception itself. [...] In either case, the exception itself is always shown after any chained exceptions so that the final line of the traceback always shows the last exception that was raised.
So, in practice, you will see both tracebacks. However, if you, say, just catch the exception with a generic "except Exception" or whatever and log it without "__context__", you will miss the firstly thrown exception.
[1]: https://docs.python.org/3.14/library/exceptions.html#excepti...