huh, many chars in the APL385 (or at least after whatever i've done with BQN386) are in the "wrong direction" (as far as FontForge is concerned), resulting in way worse AutoHint generation (at least in some cases (especially the original box drawing chars which weren't hinted at all..))
To be fair, it's also compiling programs x → 1÷x for reciprocal and w,x → w+x for Or. The last one had to be shortened from (w+x)-w∧x to avoid a stack overflow error.
@dzaima If you're busy, I can start fixing things up.
@dzaima Yeah, missing leading axis agreement. The scalar dyadics are as well, and dzaima+reference doesn't correct for those, but fortunately I never need it.
@dzaima Stack size increase works. Only 38s for the full "1-2" compile!
@Marshall trough the couple nights of sleeping on it i haven't come up with a good way to handle the scalar built-in pervasion. It's either repeatedly calling the single item case (java might or might not like the repeated virtual interface method calling) or creating an expanded argument array (definitely not efficient)
@dzaima Sometimes Dyalog creates an expanded argument array because it is faster (elements vs short rows in particular). I'd say replicate out to ~4K chunks. The extra memory usage won't hurt anything.
@dzaima It's a weird feeling, but at the end it's all just code. No way to notice the tower of abstraction, unless for example you're somehow aware of time passing.
@dzaima (i have the last couple lines a bit different for the different use-cases, unfortunate that there's no real way to avoid needing to comment/uncomment the lines (might need to add file arguments at some point but no clue how would the scoping of that would work))
@Marshall that was exactly what i was thinking of, but then also thought of being able to do •EX "filename" arg1 arg2 at which point the location of •args starts mattering or something
(i still don't use java -jar BQN.jar filename for anything, so that could easily allow passing trailing arguments (with -f filename things after it are interpreted as more flags, maybe it's worth just throwing that out too while at it))
@dzaima yeah, turns out the automatic direction correcter screws up almost always on characters with intersecting parts.. To be fair, it also complains about them (or did before i aggressively ignored all errors and warnings)
@Marshall do you actually execute testref.bqn or is it just a storage of tests for now? i.e. it doesn't seem anything's making sure 'c'≡¯2⊑"abcd" works
@dzaima i wonder if it could make sense to hangle •args after tokenizing the entire file but before anything else
no ⍎"•args" but ¯\_(ツ)_/¯
(other option being a pseudo-new pseudo-scope - the variable hashmap and parent reference are copied over, but an args field is changed; would mean weird things with random (as it's a separate field in Scope that isn't final) but that's not used anyway)
@dzaima it's been surprisingly extremely fun playing around with hinting (e.g. no clue what the stem hints do exactly, but adding them in a couple non-stemmy places in ⍋⍒ made them look better so ¯\_(ツ)_/¯), but i should go sleep now
@xpqz I'll try to remember this message. I really want the dfns workspace to be a GitHub repo so we can take PRs, but reports, suggestions, questions, etc. Right now, it is in a kind of stand-still limbo since John Scholes died.
@dzaima Better, and in some places better than my current APL386, but still, in too many places it has awful skewnesses. Go here and add body{font-family: 'BQN386 Unicode'} then toggle that on and off to see the differences. Make sure to try it at various zoom levels.
@dzaima No, you're right. charmap must be doing something wrong here. If I use it, I get --
@dzaima I doubt it. I don't recall it ever being used. It may simply be an alternative shape for the "erase to the right" action, or simply a mistake. I'd say change it.
@Adám still have no clue what the name will end up as, so better make it not either ¯\_(ツ)_/¯
@Adám right, that would be preferable, but unless i start again from your version and import chars ontop of it, i doubt i'll be able to achieve the original hinting accuracy
so for the time being i'm keeping it somewhat separate, until it's undoubtedly better
@Adám as far as i understand, "encoding" is about what "things" the font supports, and the empty chars might be pretty important in regards to that. Obviously very unrelated to what we're trying to do
(i changed small things about a couple chars (⍋⍒N, a couple superscripts & subscripts and maybe a couple more) for better hinting but no other reason too)
@Adám the ▃▄▅…? i did align the bottom line of the, but it didn't help, so practically no (and i think it's better to keep them anyways, APL385 has some extending magic for them or something)
@Adám among things i changed are +-÷←→⊣⊢ (because i had settled on the center line being the one i made for ⊖ and stubbornly changed everything else and not it..)
at some point i'd like to redo much more of everything, but that's not now
@AviF.S. the different sizes are extremely important for that - some problems show up only at certain sizes (originally i had 2x as many sizes, but that made the gif too large to upload here (i also had them cycling 2 times between apl/bqn but that made the gif another 2x larger..))
@AviF.S. e.g. abcdefghijklmnopqrstuvwxyz are all exactly equal between APL386 and BQN386, the only thing that differs is the hinting rules (e.g. what parts should align how to the pixel grid of the screen)
@AviF.S. Probably our fault for using names loosely. These are two fonts, one is called APL386 and the other BQN386. They have no inherent connection to languages.
When a character is missing, a blob is shown instead.
The idea though is to have the BQN codes that aren't used by APL, show up well in APL, so one can use at least a subset of BQN without having to change over. If those chars won't be used anyway
@Adám Understood. So I was wondering about having those characters not be missing, since they're unused anyway
@AviF.S. i did enlarge ○ and the related things about it, aligned some center lines, but otherwise everything else is exactly equal. The huge difference is because of the hinting differences
APL386 kept APL385s hinting, the BQN386 there was completely rehinted & reinstructed by FontForge, sometimes leading to better results, sometimes worse
@AviF.S. APL386 was made before BQN existed, noone (before me and BQN386) made characters for them. Then i made BQN386 by adding the needed characters to APL386, somehow screwed up hinting and auto-rehinted everything
@Adám i purposefully wanted it to be able to handle very wrong syntax in case there's some bash/java mixed in
(mixing languages mid-paste is still something i'd like to be able to do)
@dzaima (also allows for the diff "language" to color the individual lines without caring about mismatched brackets (multiline comments do break, but ¯\_(ツ)_/¯))
@Adám what would distinguishing quads do? (also dzaima/APL has a lot of quads, they might change at any time, and i want to be able to add built-ins/quads without needing to also continuously update paste (a bigger problem would be if the discussion is about adding stuff, in which case adding to paste already would not make sense))
(all of this stems from paste being a code display thing, not for editing/IDE)
@dzaima One of the issues with APL is it is hard to parse because one doesn't know the syntactic class of elements. By colouring quad names, one can see their syntactic class.
It'd be nice to colour /\⌿⍀ as function if before an operator or after a dyadic operator.
Keep executing the last line. The first line runs in the background and continuously randomly redefines ∆ as a function or an array, so the second line means either 1~1 or ⊢~1 depending on the exact moment it is called. Which one is not predictable in any way.
@dzaima Yeah, forgot that one, as I didn't have the comparison image. Now I can go through and copy the remaining ones, and the ones where BQN is better.
@dzaima Yeah, what's up with that. I copied with hinting etc. from your font, and look at the image I sent; some of the think+thin are completely crazy. It seems the specific application that renders has a huge influence. I used Microsoft Word this time.
@dzaima Sure, but I think applications are free to use their own, and both Dyalog's IDE and Microsoft word and Firefox use something else than the default (ClearType, I think it is called).
if you select all the heavy box chars and shift+ctrl+h & ctrl+t them, does anything change? (theoretically nothing should be different as that's how they were originally hinted, but maybe something went wrong in the copying process and whatever renders them for you decides that the hinting is totally screwed up and goes with auto-hinting?)
so something in the transfering broke freetype but left whatever windows rendering okay. shift+ctrl+h & ctrl+t does fix it on my end, but that'd have to be done on all changes
(fontforge definitely isn't "the best", i'm mostly using it as a means to pack svgs to a working font)
(i wish the hinting information was editable externally too; though haven't really tried many things to import/export it)
Most accurate implementation right now is this mess that I'm calling dzaima+reference, which is a dzaima/BQN script that defines covers for the primitives that don't match the spec now and preprocesses its input to use those covers. It's usable but has some bugs and gaps and is very slow.
