I haven't looked at the API yet, but the demo is great on my phone. Instead of just justified blocks, can you have it do a "justified" (even amount of spacing) from an irregularly shaped right edge (in my case, an image on the right side of a design template I made)?
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've always admired these sorts of illustrations. Botanical ones too. Please forgive the newb questions, but does this gorgeous illustration style have a name and how was it done (I.e., what is the medium -- some kind of colored ink?)
"The plates were originally engraved in steel to ensure fine lines before being hand-colored on the small prints which measured only approximately 4 × 6 inches...
Once the black-and-white images were printed, they were passed to teams of colorists who applied watercolors by hand."
I hate to be a contrarian, but I've always hated them. IMHO, the extra-fancy-style illustrations are just that. Now that we have wildlife photography, these seem to regress and appear much worse (again, IMHO) because they are literally an illustration of reality and not a snapshot: https://www.youtube.com/watch?v=NwhVJ7cv9B4&t=36s
Click on the visualizations to see it in action. The purple areas are areas a user highlighted to tell the system to inpaint, and when you click on the image you see the results of the inpainting. Basically the model redraws sections of an image (the purple areas) using the context of what's in the non-purple areas to decide what might look best in the purple areas. Often used for removing objects but as you can see in the examples it can do other things too.
Because they appear to have a curious way of doing their saves. From the article:
>The way Slay the Spire allows you to save and resume runs is by storing the total number of times each RNG has been called, and then calling each RNG that many times (throwing away the result) whenever a save file is loaded.
Depending on what the game is like (I know nothing about it), that could make sense, even if it is inelegant.
That's just to restore the internal state when you reload your save file, so that, for instnace, if you save and quit while looking at a set of card rewards, but haven't made your choice yet, when you reload, you will see the same set of rewards (you can't just reload your save to reroll).
This doesn't really have any impact on the gameplay, and isn't related to the correlation problem, it's just a constraint on the class of RNG algorithms in use, they need to be deterministic with recoverable state.
I thought this was the release where the built in sqlite got its experimental tag removed, but I don't see it in the release notes. THAT'S got me excited more than Temporal. A stable API, huge utility and one less dependency.
Wow, surprising that it was zero. Is there a chance that the cup was being separated from the tracker at a sorting facility with the cup going to a different destination than the tracker?
I've heard of this before. Activists put trackers on recyclables and the automatic sorter removes them because they have metal, and the activist gets outraged that the item went to the trash.
they said they had 53 trackers and only 36 "returned usable data" so theoretically some of those unaccounted for 17 could have been recycled... I mean they don't know what happened to them. I think they could have at least highlighted that in the article.
Because it was the only "standard" 256-color mode back in the day, supported by both mcga and vga. MCGA cards had just enough ram to support this mode (64kb) while vga cards were a strict superset and had a full 256k of ram.
The memory is organized differently, where VGA has to use 4 memory chips and spread a byte of memory among them, while MCGA just keeps it simple and uses one byte of memory per pixel.
Technically in MCGA mode VGA doesnt spread individual pixel bits among banks, pixels are kept "whole" as bytes in banks/planes. 13h is the only mode that doesnt benefit from all of that complicated EGA inherited machinery, yet it still became the most successful and practically synonymous with VGA :)
>I'd certainly say PWA is something that could only come out of the mind that brought us Kubernetes
How so? PWAs are awesome! Democratizing for users. Democratizing for developers. They work well for the right class of apps. They would go much further if there weren't forces actively resisting them. Think of all the electron type-apps out there. Now imagine if the average Joe could just install them from the web with 2 clicks.
(Regular ole bookmarks get you a decent percent of the way but clearly something extra than that was needed.)
reply