:D Sounds like a splendid plan. Do you know whether there's an LLM running inside TeX available?
the modern method would be to embed a prompt "which key is that" and call an AI :-)
Or I make any resolving an error and only execute the match as a form of error recovery (so people would fix their wrong keys/choices but a first pass in nonstopmode or batchmode would still yield a most likely correct result)
And the amount of code I'd have to write for it would be quite some (it needs sorting to build the tree, afterwards we can traverse by a recursive algorithm to build the tree (we'd need splitting at the centre, so it'd need two passes on each node, one to count the viable children one to actually partition), all in all tree building will take some time, the question is how much, then later traversing the tree won't be lightning fast, but reasonable well; and the space efficiency would most likely be rather poor)
So, whenever a `choice` isn't exactly matched this mechanism kicks in as error recovery. It could be used to only give better error messages, or it could be used to silently correct such errors (but as I said, since `expkv` is fully expandable, and this would be as well, that'd mean I couldn't issue warnings whenever this happens).
I meant like an extension to `expkv`, installing unknown-handlers that do exactly that.
By system you mean just a system or an operating system? If prior, describe more. If latter, which one?
Gerd shared a sneak peek of the new ctan design: https://mastodon.social/@GerdNeugebauer/116079728604665610
What a clever bird! https://www-spiegel-de.translate.goog/panorama/bremen-verletzter-kormoran-klopft-in-notaufnahme-an-a-bafd85ef-d971-4932-bf91-7a692292b269?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en
I have an idea for some system to get key choices auto-abbreviated and even a bit typo resilient (if the typo happens towards the end). I have not yet developed an implementation draft and don't know the performance, yet (the algorithm should be O(log n) at use time as it's basically some form of binary search -- but you never know for sure how well it behaves in TeX).
This would basically mean that for a list of valid choices `default, deprecated, foo, bar` any of the following input would work:
- `def` -> default
- `depercated` -> deprecated (anything at least starting with `dep` would do, so also `depault`)
- `f` -> foo
- `ba` -> bar
My basic plan would be to implement this fully expandable and hence I'd not be able to throw a warning that there was a choice substitution!
The basic layout would look like the following decision tree that'd be created while the choices are set up:
```
d
--------------|--------------
↓ ↓ ↓
b e f
-----|----- ----|---- -----|-----
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
ERR bar ERR ERR f ERR ERR foo ERR
-------|------
↓ ↓ ↓
ERR default p
--------|---------
↓ ↓ ↓
ERR deprecated ERR
```
You read it like this: Coming from the top if the current character in the input matches the tree node go straight down and move to the next input character, if it's charcode is smaller go below left, and if it's bigger go below right. Each node called `ERR` is an error message picking up any non-`ERR` leaf node of its parent as valid choices and generating an error message along the lines of "ambiguous input <input>, did you mean any of <list-of-leafs>?". Any multi-letter node is what I called a leaf node (a valid final result).
Do you think people would be interested in this?The pixelated headings aren't an issue, the actual text is behind the pixels in white, so a screen reader should do the right thing, I guess, and tagging should be almost fine. Also I don't necessarily need the documentation to be tagged correctly, first step would be to correctly support an `alt` key that does the right thing once `tagpdf` is loaded/`\DocumentMetaData` was used.
I took a quick look yesterday and see a number of "Baustellen" ;-(. It would help if the docu would use lualatex. For l3doc you need a supporting sty we have in latex-lab. For the listings you need (at least) some definitions that I have in the tagpdf-docu-patches. enumitem is only partially supported, so some keys must be adapted (and you must also remove the space before the optional argument of description, but that will perhaps change). titlesec is not supported so you need to replace that. And you need something to add actualtext to your pixelated headings.
I think you could get away with creating two or maybe three copies of macros to make things work again.
I know. I had to split a presentation into two files because of this :P
I know of a second package of yours that's broken in combination with another one which is mine.
The 7 in the Kinsley one is horrible, but I was speaking of the 4 in Transport.
Bad news: one of my packages is broken Good news: it is only broken in combination with one specific other package, so I will simply blame the other package Bad news: the other package is also by me :P
Last step to warrant an update for `pxpic` shipping the new prettier? documentation: I'll need to get it tagging ready. I have no idea how to do that :)
Yes, we rabbits are really good at trickery! (we learned from tortoises)
taking a look at the sources: white coloured text below the pixel font.
@samcarter You might have another look, I changed some glyphs a bit, to get a crudely similar metric to the normal text and used a small hack to make the text searchable and copyable (I previously tried to get that via `accsupp` but that wasn't working out too well -- or rather it didn't work for my viewer)
I keep to my words from the documentation (though on a different matter): > blame the viewers.
which pdf viewer do you use? I didn't see these vertical white lines with mac preview.
I am both nearsighted and farsighted and I don't understand if it's my eyes or the font made like that
interestingly, I find that the headings do stick out because of their different greyness in particular. Nevertheless I increased the font size by another step to make the pixel effect more noticeable (so now we're at `\huge` for sections, which is, well, already quite huge)
Covers my findings pretty much. The font size was already increased once, but another step might be a good idea.
I just tested with the pdf. It is probably a matter of taste, but personally I would increase the font size a bit: - with the pixels, the font looks gray and does not stand out very much compared to the surrounding text (pot/kettle: I also have a package with gray headings and I should change that, but it is so pretty if all the package docs follow a colour gradient -- until one runs out of distinguishable colours...) - when opening at 100%, the pixels are not immediately noticeable. A bit bigger might allow more users to enjoy this Easter egg.
you could try, I heard the changes are already in the repository and you could clone it and run `l3build doc` on it, to check how it's looking in your PDF viewer.
looks very pixelated, you should install the `cm-super` package -- oh wait :P