https://obsidian.md/blog/json-canvas/

The ar format is underrated.

... which may have really happened, per se, but it didn't wholly incorporate (subsume/cannibalize) conventional desktop publishing, which is still in 2023 dominated by office suites (a la MS Word) or (perversely) browser-based facsimiles like Google Docs. Because the Web as it came to be used turned out to be as a sui generis medium, not exactly what TBL was aiming for, which was giving everything (everything—including every existing thing) its own URL.

What if you just dropped your pre-rendered static assets into the new system?

The Web does not yet meet its design goal as being a pool of knowledge that is as easy to update as to read. That level of immediacy of knowledge sharing waits for easy-to-use hypertext editors to be generally available on most platforms. Most information has in fact passed through publishers or system managers of one sort or another.

For this part, probably we would combine the techniques shared in the notes of the previous entry with Brea, our Pharo powered tool between a static site generator and decoupled CMS.

All this detailed manipulation re/decomposing tiddlers in other formats or adding tiddlers content in a programmatic way is done via TiddlyWikiPharo and inside a single language. For external functionality not implemented or too slow in Pharo (for example YAML to JSON conversion) we try to program it in Nim and create a Pharo wrapper around the Nim binary output.

For this, we use Pandoc's YAML metadata blocks or approaches inspired by it. Our data publishing package MiniDocs (which is a prerequisite of TiddlyWikiPharo), provides a YAML metadata importer/transformer to native Pharo dictionaries that can be added to tiddlers. An alternative route from tiddlers metadata to Markdown could be easily implemented (but, as told our focus has been Markdown to WikiText migrations so far)

We do this in a semi-automatic way, as the manipulated tiddlers inside TiddlyWikiPharo powered data narratives are exported as a single JSON file that is dropped back into the single HTML file we they came from, before manipulation. Some automation could be implemented in the future, maybe with a simple Nim TW server (as we try to avoid JS incidental complexity as much as we can, including/particularly node).

TiddlyWikiPharo is capable of similar exportation and we start from the single HTML TW file that we can de/recompose almost at will, because we can manipulate the tiddlers inside a data narrative. As shown in the malleable systems wiki example, we're mostly focused in conversions from Markdown to WikiText (TW's format) as it is our most felt necessity, but migrations from WikiText to Markdown are in the radar, combining/extending TiddlyWikiPharo with Pandoc (future needs/funding will tell if/when is implemented).

@1:10:20

With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]

NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.

It's worth introspecting on why any given person might hesitate to feel that they can commit. This is almost always comes down to "maintainability"—websites are, like many computer-based endeavors, thought of as projects that have to be maintained. This is a failure of the native Web formats to appreciably make inroads as a viable alternative to traditional document formats like PDF and Word's .doc/.docx (or even the ODF black sheep). Many people involved with Web tech have difficulty themselves conceptualizing Web documents in these terms, which is unfortunate.

If you can be confident that you can, today, bang out something in LibreOffice, optionally export to PDF, and then dump the result at a stable URL, then you should feel similarly confident about HTML. Too many people have mental guardrails preventing them from grappling with the relevant tech in this way.

This page is excellent for an example of HTML being an adequate substitute for traditional office formats.

This is where I think Glitch goes wrong. Why such a focus on apps (and esp. pushing the same practices and overcomplicated architecture as people on GitHub trying to emulate the trendiest devops shovelware)?

"Web" is a red herring here. Make the Web more accessible for app creation, sure, but what about making it more accessible (and therefore simpler) for sharing simple stuff (like documents comprising the written word), too? Glitch doesn't do well at this at all. It feels less like a place for the uninitiated and more like a place for the cool kids who are already slinging/pushing Modern Best Practices hang out—not unlike societal elites who feign to tether themself to the mast of helping the downtrodden but really use the whole charade as machine for converting attention into prestige and personal wealth. Their prices, for example, reflect that. Where's the "give us, like 20 bucks a year and we'll give you better alternative to emailing Microsoft Office documents around (that isn't Google Sheets)" plan?

It's not nearly as timeless as a person might have themselves believe, though. (That's the "predilection" for certain technologies and doing things in a certain way creeping in and exerting its influence over what should otherwise be clear and sober unbiased thought.)

There's basically one timeless API, and that means written procedures capable of being carried out by a human if/when everything else inevitably fails. The best format that we have for conveying the content comprising those procedures are the formats native to the Web browser—esp. HTML. Really. Nothing else even comes close. (NB: pixel-perfect reproduction à la PDF is out of scope, and PDF makes a bunch of tradeoffs to try to achieve that kind of fidelity which turns out to make it unsuitable/unacceptable in a way that HTML is not, if you're being honest with your criteria, which is something that most people who advocate for PDF's benefits are not—usually having deceived even themselves.)

Given that Web browsers also expose a programming environment, the next logical step involves making sure these procedures are written to exploit that environment as a means of automation—for doing the drudge work in the here and now (i.e., in the meantime, when things haven't yet fallen apart).

Although the generated code is very useful...

This is wrong. It treats the ZIP format as if (à la PNG) it's a concatenated series of records/chunks marked by ZIP's characteristic, "PK" off-set, 4-byte magic numbers. It isn't. The only way to read a ZIP bytestream is to start from the end, look for the signature that denotes the possibility of the presence at the current byte offset the record containing the central directory metadata, proceeding to validate* the file based on that, and then operating on it appropriately. (* If validation fails, you can continue scanning backwards from the offset that was thought to be the signature.)

The first passed validation attempt carried out in this manner (from back to front) "wins"—there may be more than one validation passes beginning at various offsets that succeed, but only the one that appears nearest to the end of the bytestream is authoritative. If one or more validation attempts fail resulting in no successes, the file may be corrupt, and the implementation may attempt to "repair" it (not necessarily by making on-disk modifications, but merely by being generous with its interpretation of the bytestream—perhaps presenting several different options to the user), or, alternatively, it may be the case that the file is simply not a ZIP archive.

This is because a ZIP file is permitted to have its records be little embedded "data islands" (in a sea of unrelated bytes). This is what allows spanned/multi-disk archives and for the ZIP to be modified by updating the bytestream in an append-only way (or selectively rubbing out parts of the existing central directory and updating the pointers/offsets in-place). It's also what allows self-extracting archives to be self-extracting: foremost, they conform to the binary executable format and include code for being able to open the very same executable, process the records embedded within it, and write them to disk.

Almost every time I've used FedEx's "Print and Go" for a PDF I've created by "printing" e.g. HTML (and that I've verified looks good when previewing it on-screen), it comes out mangled when actually printed to paper.

Economic Action Plan 2015 Act, No. 1, SC 2015, c 36, https://canlii.ca/t/52m2b, s. 171(1) repealed IRPA s. 14(3), which had said: "(3) For the purposes of subsection 11(1.01), the regulations may include provisions respecting the circumstances in which an application may be made by other means and respecting those other means."

Economic Action Plan 2015 Act, No. 1, SC 2015, c 36, https://canlii.ca/t/52m2b, s. 171(2) repealed IRPA s. 14(4), which had said:

(4) The regulations may provide for any matter relating to the application of section 11.1, including (a) the circumstances in which a foreign national is exempt from the requirement to follow the procedures prescribed under that section; (b) the circumstances in which a foreign national is not required to provide certain biometric information; and (c) the processing of the collected biometric information, including creating biometric templates or converting the information into digital biometric formats.

Economic Action Plan 2015 Act, No. 1, SC 2015, c 36, https://canlii.ca/t/52m2b, s. 171(3) repealed IRPA s. 14(5), which had said:

(5) The regulations may require foreign nationals who make an application for a visa or other document under subsection 11(1) and foreign nationals who were issued an invitation under Division 0.1 to apply for permanent residence to make those applications by means of an electronic system and may include provisions respecting that system, respecting the circumstances in which those applications may be made by other means and respecting those other means.

Referenced in an HN thread:

https://news.ycombinator.com/item?id=12793157

In the thread, William Woodruff mentions that LibreOffice is capable of displaying this file.

I've advocated for a different approach.

Most of these "rich formats" are, let's just be honest, Microsoft Office file formats that people aren't willing to give up. But these aren't binary formats through-and-through; the OOXML formats are ZIP archives (following Microsoft's "Open Packaging Conventions") that when extracted are still almost entirely simple "files containing lines of text".

So rather than committing your "final-draft.docx", "for-print.oxps" and what-have-you to the repo, run them through a ZIP extractor then commit that to the repo. Then, just like any other source code repo, include a "build script" for these—which just zips them back up and gives them the appropriate file extension.

(I have found through experimentation that some of these packages do include some binary files (which I can't recall offhand), but they tend to be small, and you can always come up with a text-based serialization for them, and then rework your build script so it's able to go from that serialization format to the correct binary before zipping everything up.)

I read this post and wonder why Gutenberg doesn't solve the problem by allowing a theme to target all of these options, even when multiple post formats are used in the same post?

Post Kinds is a great example of extending Post Formats, but it needs to be dovetailed into the Gutenberg way of doing things.

It's unfortunate, but I can understand why they decided this way.

https://bugs.ruby-lang.org/issues/15958

The hex spells lint not list, also in a real WAV file it appears to be capitalized LIST = 0x4C495354

hi there check this link on SAS training and tutorial with the detailed explanation on the Base Training of that along with real time Examples and Projects practices

https://www.youtube.com/watch?v=IOxaKq4lB-0

hi there check out the SAS Basics Training and Tutorial with better Explanation on the Analytical tools and data workflow in the databases https://www.youtube.com/watch?v=wNQLAUaaMHE

That's an awful lot of models. Are we to understand that these are all limited to WMA, a proprietary format, and this is hard-coded so that it cannot be overcome with a software/firmware update? Seriously?