TeX - TopAnswers

Skillmon replying to निरंजन

I think I tend towards the same (and basically current) solution. Though one could still use that code to throw more meaningful error messages (though they might sometimes be off -- but I seriously doubt whether that warrants the amount of code to put in)

निरंजन replying to Skillmon

I think it's much safer to simply say "wrong input, go and correct it." I don't have any mercy for mistaken code.

Skillmon replying to Ulrike Fischer

:D Sounds like a splendid plan. Do you know whether there's an LLM running inside TeX available?

Ulrike Fischer replying to Skillmon

the modern method would be to embed a prompt "which key is that" and call an AI :-)

Skillmon

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)

Skillmon

I could also implement this in Lua, but then it'd be LuaTeX only, which I'd like to avoid.

Skillmon

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)

Skillmon

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).

Skillmon replying to निरंजन

I meant like an extension to `expkv`, installing unknown-handlers that do exactly that.

निरंजन replying to Skillmon

By system you mean just a system or an operating system? If prior, describe more. If latter, which one?

samcarter

Gerd shared a sneak peek of the new ctan design: https://mastodon.social/@GerdNeugebauer/116079728604665610

samcarter

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

Skillmon

One could use exactly the same system to also resolve key names.

Skillmon

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?

Ulrike Fischer replying to Skillmon

well show a small example and I can take a look.

Skillmon replying to Ulrike Fischer

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.

Ulrike Fischer replying to Skillmon

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.

samcarter replying to Skillmon

I was considering this, but went the easy route.

Skillmon replying to samcarter

I think you could get away with creating two or maybe three copies of macros to make things work again.

samcarter replying to Skillmon

I know. I had to split a presentation into two files because of this :P

samcarter replying to Skillmon

Ah, yes. The 4 there indeed looks odd.

Skillmon replying to samcarter

I know of a second package of yours that's broken in combination with another one which is mine.

Skillmon replying to samcarter

The 7 in the Kinsley one is horrible, but I was speaking of the 4 in Transport.

samcarter

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

samcarter replying to Skillmon

I find the 7 much worse :)

Skillmon

TIL that the 4s on British road signs look ugly.

samcarter

https://mendeddrum.org/@fanf/116059833855582074

Skillmon

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 :)

Skillmon replying to निरंजन

Yes, we rabbits are really good at trickery! (we learned from tortoises)

निरंजन replying to AnonymousRabbit

Oh! Smart :D

AnonymousRabbit replying to निरंजन

taking a look at the sources: white coloured text below the pixel font.

samcarter replying to Skillmon

In mac preview, it looks nice.

निरंजन replying to Skillmon

What are you using now?

निरंजन replying to Skillmon

:P

Skillmon

@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)

samcarter replying to Skillmon

Blaming the viewer always works :P

Skillmon

Also: Let's call it "font" instead of font :) Afterall every glyph is a `\pxpic`.

Skillmon replying to CarLaTeX

I keep to my words from the documentation (though on a different matter):  
> blame the viewers.

Skillmon replying to samcarter

well, it's Acrobat. Of course it's not pretty.

samcarter replying to CarLaTeX

Oh! I can confirm with acrobat on macos - not pretty!

CarLaTeX replying to samcarter

Acrobat on Windows

samcarter replying to CarLaTeX

which pdf viewer do you use? I didn't see these vertical white lines with mac preview.

samcarter replying to Skillmon

This makes a huge difference :)

CarLaTeX replying to AnonymousRabbit

I am both nearsighted and farsighted and I don't understand if it's my eyes or the font made like that

CarLaTeX

![blob](/image?hash=0f0cc5c4fbd04545534cf5e03bd88941e89e7dca81289ec627926b2be4cb6197)

Skillmon replying to samcarter

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)

AnonymousRabbit replying to samcarter

Covers my findings pretty much. The font size was already increased once, but another step might be a good idea.

samcarter replying to AnonymousRabbit

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.

AnonymousRabbit replying to CarLaTeX

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.

samcarter replying to Skillmon

looks very pixelated, you should install the `cm-super` package -- oh wait :P