lyall

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.

I’m in the exact same situation. I’d like to drop emacs for Zed but magit keeps me coming back. That and Zed’s vim emulation isn’t quite up to par yet.

Good opportunity to repost this gem: "Parsing the Infamous Japanese Postal CSV" https://www.dampfkraft.com/posuto.html

HN discussion: https://news.ycombinator.com/item?id=25023673

FWIW The Japan Times is a fully English language publication, so no need to excuse anything based on language ability

The whole system is quite tightly controlled by the transit companies (e.g. JR East). For example, your average payment terminal can take money off of a card but not load money onto it (refunds have to be done out of band). Loading money onto cards is more privileged, as it’s equivalent to printing money.

One other limitation in place is that these transit cards have a limit of ¥20,000 (~140 USD) max that can be loaded on to them. So any transaction larger than that is out of the question.

So to answer your question, no this isn’t really a person-to-person cash replacement. It’s a transit card that happens to be able to be used as an offline payment method, but it’s got various limitations and weirdness that prevent it from being something more.

Kotlin is gaining steam in the Java world. We're moving to make it our default server-side language at my company instead of Java. Given its great Java interop, you can basically think of it as a modern, more functional Java that doesn't have multiple decades of baggage associated with it. I highly recommend considering it in any place you'd consider Java.

Black companies certainly still exist and still mistreat their employees—I know quite a few people that work a lot of overtime with no extra pay, experience パワハラ, are the longest tenured employee around after just one year because of the massive turnover... Just because some people (you, the other people you mention) don't experience this doesn't mean nobody else does.

It's "Up to $800" for an "iPhone 12 or newer". You won't get more than $200 for trading in an iPhone 12. The max value is reserved for the newest and highest end phones, i.e. 15 Pro Max.

In article form: https://www.bloomberg.com/features/2024-roblox-pedophile-pro...

I'm not sure exactly what GP is referring to, but it might be things like this?

Facebook report they maintain an allow-list of queries extracted from from their source code at build time, to fix this. I've not seen any other GraphQL site do this

https://x.com/AdamChainz/status/1392162996844212232

Which references this article: https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...

I don’t believe there is any evidence that vitamin C reduces inflammation or helps with depression. Vitamin C is an antioxidant, not an anti-inflammatory agent.

There is evidence that things that reduce systemic inflammation help with depression. Fish oil, or more generally a balanced omega-3/omega-6 intake is one example. Curcumin is another. However the effects are modest, which is probably to be expected with a condition as diverse as depression.