"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'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.
> Is it because people think the topic is interesting but don't actually care about the content?
I'm having difficulty seeing where you draw the line between “topic” and “content”. I found the article interesting as it taught me a few things that I didn't already know. I did notice the one egregious AIism that you pointed out, but the rest was readable and informative. (Although I stopped at the point where it started talking about their software Fink.)
A closer analogy is going to a gas station where a microwave is offered to heat up any food you purchased. If you don't want to heat up the food, cool. If you expect the food to come hot you're in the wrong place.
Except in this case it's a gas station that only exists for the benefit of its owners and there isn't any food for sale. The owners have graciously said you could still use the microwave if you'd like, though.
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".
Not quite. A "thin space" is thinner than an ordinary interword space, which in turn is thinner (or at least less stretchy) than an intersentence space. The space in "No. 12" or "Fig. 7" or "Mr. Jones" or "cf. page 5" is by definition an interword space! The problem is that HTML renderers tend to prefer to set it as an intersentence space instead, because they think "." always indicates the end of a sentence. Using can help; that's like "~" in TeX. TeX also supports a breaking-but-never-intersentence-sized space via "\ " (backslash space), which is what you'd probably want to use in "cf.\ page~5." AFAIK, HTML/Unicode have no equivalent of that.
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.
> 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.
This philosophy has been growing on me - a coworker framed it as “nuance melts away with LLMs”
I recently wanted to render a 100+ page document in an interactive WYSIWYG editor using a single stroke font and join the letters to form single stroke cursive words that appeared handwritten.
The permutations of rulesets that governed connections between letters (I.e. how does t connect to c, and do you need to lift the pen to make that connection) amplified by the randomness injected into the strokes and line width/angle (handwriting doesn’t have uniform letters or lines!) would have been intractable previously.
But, with an agent harness, I could do 3 or 4 examples of what “right” looked like - give it the ability to generate and screenshot test cases to see the output of its work - and it could grind through a reasonable ruleset for about $20 in spend.
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.
"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."
reply