FourthWorld wrote: ↑Fri Aug 23, 2024 10:28 pm
if you needed to parse with style and link info retained, MC's htmlText was reliably consistent, and inspired by HTML conventions it felt familiar and was easy to work with, a good solution for its time.
Ah gotcha, that makes sense for the early 90s, it would've been one of the only widely used XMLs around then.
StyledText arrays were added by Mark Waddingham about 20 years later, a few years after arrays became multidimensional. They are the closest representation to the binary style run data the engine uses internally, super efficient to work with, and now the recommended way to work with styling outside of fields.
Yes, I try to use arrays whenever I'm looking for fast lookups, and having the text formatted with key/values pairs that match the xTalk properties is rather a nice too.
RTF is a messy format and only includes the subset of styling information common to both that core RTF spec and MC. It was designed for quick exports for use in word processors.
Right, RTF is a Microsoft created format (IIRC?), but pretty common now, Apple has used it too since acquiring NeXT, and has a .bundle version called .rftd that can include images and other resources.
MC on Unix even supported EPS (Postscript)!
MC supported
Display Postscript, famously used by NeXT and IIRC later adopted by at least one other Unix vendor (Silicon Graphics?)
Probably Sun Microsystems too IIRC, I used to deal with several Sparc stations, and for a short time some SGI (Irix was the OS) Indigos and Octanes (SGI made
THE coolest computer cases) back when.
There's also GhostScript and other PS interpreters around. Ghostscript is FOSS I believe.
Postscript is a full fledged programming language, it doesn't
have to be used for only Printing, although that was obviously its most used case.
I know some about it, having been very interested in PostScript in those days. I read several books on the subject anyway, and I knew enough that I could write postscript 'page programs' including embedded PS Font to a .ps file and download it directly to a PostScript printer, sans a visit to 'the Chooser" or Print Dialog Box from within a HyperCard stacks (with a few extra externals). Great for creating a large catalog of thousands of fonts specimen sheets back when people did that sort of thing. Now days Printers don't even use Postscript as its cousin PDF has largely supplanted it.
Something I did't know much of until recently reading about it was was NeWS (Window Server) and HyperNeWS hyperMedia system much like HyperCard but used Postscript as it's scripting language. That looks like a fascinating environment to have played around with.
I'm curious about how that EPSObject would've worked, like placing an EPS in a Quark or PageMaker Document I imagine, much like putting SVG into an Image Control that we can do. EPSObject is still available in the engine but obviously no longer functional since there's no Display Postscript OS's around since Apple used their Quartz rendering engine instead.
Before the ubiquity of JavaScript made JSON the go-to serialization format, the world was enamored with using XML for that role.
Although HTML is XML-like, it's famously not XML, and often won't survive XML parsing.
Yes, there's a few of those non-conformant MLs around.
I find XML (strict or not), is more readable when hierarchically tabbed (beautified), then JSON is to look at just due to the verbosity of it. Which of course is a disadvantage when transmitting the data across wires, where sparseness is better, JSON makes much more sense for documents going across networks. I kind of like the idea of Yaml as for its middle of the road take on that sort of serialization.
Whatever the reason for the HTMLText prop, it was a smart choice since HTML Tags are still very much useful in today's world.
3dbox and maybe a few other tags since aren't found in HTML.
OK, maybe not so much '3dox' or 'Shadow' as Font styling tags, styles that are largely universally deprecated remnants of bitmap font era. I suspect they're still in the Engine only for compatibility with HC / ancient xTalks.
Wanna see an exciting future that won't happen? Look at Dan Gelder's HyperTalk-to-JavaScript transpiler. With oxTalk being so much larger than HyperTalk, and so few people remaining using xTalks, I can't see a business case for extending it.
That's fine with me, I'm not really looking for a business use case. I just love the entire idea of it. It being an HTML doc, it's as portable and extensible as anything else that's built as html5/JS webapp, and because of prudent design decisions, it's pretty damn easy to extend the language interpreting too! Add in a few wrappers for some choice JS libraries and it could be doing some really cool things inside that web page.
