lyall

"Hanako, my lovely wife, should we settle down and have kids?"

"I want nothing more than to raise a family, but alas I simply can't face brining a child into a world in which people applying for citizenship in this country have to present such a long list of documents."

"I feel the same way, honey."

I'm surprised that articles like this that are pretty clearly AI-generated get any sort of traction here. Is it because people think the topic is interesting but don't actually care about the content?

> Three Japanese words, three Hepburn transcriptions. The letters you already know, telling you what they sound like.

I mean come on.

> Go to restaurant

> Order food

> Food comes out as raw, unprepared ingredients

> Complain to chef

> Tells me to go cook it myself

> wtf, I'm not here to do work for free

> "Is doing something for yourself really working for free?"

There might be something valuable in this article, but if the you couldn't be bothered to write it yourself, why should we be bothered to read it?

Good call. I've updated to release script to always include the SRI hash in the README sample.

Yes! Just added support for them today after another HN user’s request: https://github.com/lyallcooper/justif/issues/3

Good eye! The space in "No. 12" would traditionally get a thin space [0] in professionally typeset documents, which is smaller than the standard space used for inter-word and inter-sentence spacing.

The solution here is to fix the sample text itself to use U+202F (NARROW NO-BREAK SPACE,  ). As opposed to the standard width no-break space it currently has for "No. 12" and "Fig. 7".

0: https://en.wikipedia.org/wiki/Thin_space

It should be when the screen width is less than 456 css px with the current configuration.

Thankfully the unit it operates on is a paragraph, not the whole body of text. Also thankfully computers are very fast these days!

I added the “Alice in Wonderland (long)” text sample to the demo as a stress test, but its paragraphs are still relatively short. I should add a sample that’s one really long paragraph and see what happens. I may need to add a bail-out after X items option if it calls for it.

The layout is done entirely in DOM. The layout engine calculates the line breaks, tracking, expansion, etc. then applies the layout using HTML spans with the appropriate attributes applied. There’s generally one span per line, but that can change for more complicated lines! I invite you to inspect the demo page in your browser’s dev console if you’re particularly curious.

And yes, I did use LLMs for the implementation, both Fable 5 and 5.6 Sol specifically. I would not have been able to achieve anywhere close to the current result unaided. My patience and expertise would’ve been exhausted long before getting anywhere especially interesting.

My philosophy with LLMs is to try to use them to achieve levels of quality and polish that would’ve been previously unreasonable. I hope this project is a demonstration of that.

That's not something justif supports directly right now. It currently targets rectangular blocks, not arbitrary edge shapes. But the underlying line-breaking approach could accommodate per-line widths, so it would be plausible to add I think.

Feel free to make a GitHub issue with details and I can take a look at supporting it. For now the workaround would be falling back to native justification by excluding the paragraph from justif, and using css float/shape-outside to get the desired edge.

It is the default if you open the demo on a narrow screen! It has a more striking difference between browser and justif layouts at narrow widths than the Alice sample. But maybe you’re right and it should be the default for everyone.

Hyphenation: yes, justif does its own hyphenation. It ships with TeX’s hyphenation dictionaries for a bunch of languages, but supports custom dictionaries as well! See https://github.com/lyallcooper/justif#hyphenation

Narrow columns: open up the controls on the demo and try adjusting the width slider :)

Long documents: try the “Alice in Wonderland (long)” sample text in the demo to get a feel for how it handles long documents. In general it performs well enough I think, though Safari is a little slower than other platforms. It doesn’t do it incrementally (not sure that’s possible), but I spent quite a while trying to make sure it was fast enough to re-layout in real time even on long documents.

I haven’t thought about coexisting. I’m not sure how that could work but I’m open to ideas.

Yes, there is something to be said for this argument. Debit card and cash users pay slightly higher prices than they might otherwise, which do subsidize the rewards of credit card users. But this is distinct from the argument presented in the article, which is that poor people's credit card debt funds rich people's airline miles.

But there factors that counteract this. Merchants pay different average fees depending on the mix of cards that they accept. A dollar store probably sees fewer Chase Sapphire Reserved or Amex Platinum cards than a Gucci store does. Accordingly, the average interchange fee they pay is probably lower. [0]

Also fee surcharging is becoming more common in the US these days, and is already common is some other countries. Visa et al. still don't allow merchants to pass on the actual interchange they'll pay, but merchants can charge a fee to credit card transactions that they don't on debit or cash.

But my original point is that giving rich people credit card rewards are not a transfer from the poor to the rich. It's a rational business decision by card companies that does not require any outside funding source, from poor people or otherwise, to make work financially.

0: There are some other factors that complicate this, such as the risk profile of the business. Riskier generally means higher fees.

You hear this argument pretty often, but it's not true.

Credit card companies do make a lot of money off of interest. But they also make a lot of money off of interchange fees.

Businesses want wealthy customers because they spend more money, so they're willing to pay a higher interchange fee to access those customers. Higher interchange fees mean card companies can offer better rewards, which in turn attract more wealthy customers to their cards.

So even if credit card debt was not a thing, it would still be incredibly profitable for card companies to sell access to their rich cardholder clientele, and to in turn provide rewards to those cardholders.

Thank you! And yes by default TeX doesn't do tracking or expansion, but the microtype [0] package does.

And I did struggle a bit with deciding how best to do the comparison to native browser rendering. I wanted it to be an apples-to-apples comparison, but also didn't want to unfairly handicap the browser by disabling something like hyphenation. It's already bad enough as is...

0: https://ctan.org/pkg/microtype

If you saw TFA and thought "hmmm yes, I know some of those words", then I can recommend the author's own lecture series on YouTube [0]. It's an intro to and overview of category theory aimed at programmers, with the requisite context and motivation for why anyone should care. It's long but worth the time investment IMHO.

0: http://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI7...

Agree with many other comments. Backrest is good and works well for me, though it certainly has its UI/UX quirks that hold it back from being truly great.

I’m going through something similar but with English instead of Spanish. That’s why I added the “kana readable” and “kana faithful” dimensions.

I don’t have a way to check built in right now. But you can look at the 2020 data here: https://raw.githubusercontent.com/hackerb9/ssa-baby-names/re...

If your name is on there it’s probably included in namex.

I could also manually check the data of course but that would require knowing your name :)

If you’ve got a name that is very rare in the US then it’s possible! Any name that had at least 15 registered births over the last three years in the SSA data is included.

I agree, the worst part about climate change is motorcyclists riding past this guy's house.

Yeah I agree. I way over-indexed on learning kanji (via WaniKani) at the beginning of my Japanese learning journey. I got about halfway through before realizing it was silly that I could read 健忘症 but didn't know many very basic hiragana-only words. It wasn't timed wasted but it probably wasn't the most efficient approach.

In an ideal world maybe learners could focus exclusively on listening and speaking first, then move on to kanji later. But writing is a very useful tool in learning, and having access to that tool can help speed things up.

Like most things in life, a balanced approach is probably the right one. But you have to know what your goal is. Our brains are lazy, they only get better at what we make them get better at. If your goal is to just read kanji, practice reading kanji. If your goal is to understand and speak the language, practice listening to and speaking the language. But if you want to have a balanced language ability, you'll need to practice it all.

When learning Japanese, I purposely chose to _not_ learn how to write any of it by hand. As the author notes, writing (by hand) is in fact a separate skill from reading. So I decided I would not invest my limited time, motivation, or brain space to writing.

Overall it's been a successful approach, and I recommend it to new learners unless they have a particular interest in being able to write by hand or they feel strongly that writing the characters helps them remember them.

It's only rarely that I have to write anything other than my own name in Japanese. I've practiced my address but writing it in English is fine in 99% of situations. Being able to write properly would save a little embarrassment, but I still believe my language learning time would have a much higher ROI in other areas.