Blips in Quick Dict.

[richmond62]

Something is going on with the interpretation of SPACE methinks:
-

Screenshot 2024-08-17 at 15.27.50.png (267.59 KiB) Viewed 2595 times

-

Screenshot 2024-08-17 at 15.28.19.png (17.73 KiB) Viewed 2595 times

-
Oh, No, it's not: Someone on the LiveCode team developed a sticky keyboard.
-

Screenshot 2024-08-17 at 15.30.59.png (97.51 KiB) Viewed 2594 times

-
Knowing them that'll still be there in LC 9.6.45

[tperry2x]

Yes, unfortunately I would have pulled everything through from the dictionary (including errors). There are quite a few errors I noticed, but at least they are standard text files (ripe for editing) now.

If anyone does correct any (which you can find at the following path), please upload any changes so I can include them in future updates (easiest way to do that is just zip the text file and attach as a post).

path:
[location of your OXT lite install] >
(if on a mac, "show package contents" > Tools >)
/Documentation/html_viewer/resources/data/api/exports/xtalk/resaved/NameOfTextFile.txt

Just because I'm a fan of having a 'stack for everything', this might help to locate them (and hopefully not just complicate matters more)

where.png (12.58 KiB) Viewed 2577 times

[FourthWorld]

Most of those anomalies serve as reminders that htmlText isn't HTML.

It's similar, and some of it coincidentally renders well in a browser. But only coincidentally; it was designed to provide full-fidelity transfer of field contents in a plain text format for use within MetaCard.

Any use in another program was not a design goal, and with modern CSS increasingly challenging to attempt to use it as such.

I've spent many years making web authoring tools in MC/RR/LC. The ones that need content editing are being migrated to web-native tech, ultimately more flexible and cost-effective when the target is a browser.

But for display within OXT, htmlText is awesome, the right tool for the right job (except where the job involves parsing; the pre-parsed compartmentalization of the styledText array is amazingly convenient and performant).

[OpenXTalkPaul]

Those "missing words" in certain entries of dictionary are a result of the tagging of keywords used in the .lcdoc markdown format. The 'missing' words are almost always exist in the original .lcdoc file, but they're tagged as a 'dictionary keyword' and are supposed to be a hypertext-links to some other related content in the dictionary. You know in the original, browser-based Dictionary when you look at an entry for 'mouseDown' there are links to related entries like 'mouseUp'.

These should really be fixed in the .lcdocs that the database for the dictionary is generated from. It would be even better to make it so the revDocsParser ensures that any badly tagged words still gets displayed.

I fixed a few of these back when LC was still 'an open-source company', it was a tedious process, it's much easier now that I know how to rebuild the dictionary data myself.

Screenshot 2024-08-23 at 4.19.47 PM.png (426 KiB) Viewed 2001 times

[OpenXTalkPaul]

Most of those anomalies serve as reminders that htmlText isn't HTML.

It's similar, and some of it coincidentally renders well in a browser. But only coincidentally; it was designed to provide full-fidelity transfer of field contents in a plain text format for use within MetaCard.

The HTMLText is actually HTML, but it's only a subset of current HTMl, it's a bit like working with old-school HTML v2.

Any use in another program was not a design goal, and with modern CSS increasingly challenging to attempt to use it as such.

I've spent many years making web authoring tools in MC/RR/LC. The ones that need content editing are being migrated to web-native tech, ultimately more flexible and cost-effective when the target is a browser.

But for display within OXT, htmlText is awesome, the right tool for the right job (except where the job involves parsing; the pre-parsed compartmentalization of the styledText array is amazingly convenient and performant).

Was that the goal of the HTMLText? If it was then that seems rather redundant when there's also 'the RTFText' and 'the StyleText', and plain old 'the text'. MC on Unix even supported EPS (Postscript)! I see no reason to include any HTML capabilities other than working on HTML formatted text.

I was writing an HTMLEditor in HyperCard WAY back in the day (early 1990s) when I ran a WebStar based site for a small business that I worked for. WebStar enabled me to use HC and Stacks as my CGI (common Gateway Interface) scripts, and I could look at form data submitted from web forms in a text field within the 'CGI' stack. My HC based WebPage editor supported a lot of HTML2 (4?) tags, and used LaunchURL (external) to preview the pages in Netscape and IE (and probably AOL's Browser). That was long before there being standardized JavaScript or cascading style sheets, DHTML, etc. that has made building websites an increasingly complicated matter. I called 'it Tarantula' and it worked pretty well, better than manually typing tags which was the only other way to do HTML at the time, but I gave up on it when Adobe released the first WYSIWYG HTML editor called PageMill (which made bloated HTML pages with many unnecessary tags).

I've recently become intrigued with the idea that 'the styledText' of a field is actually an Array, with each line of text being a top-level element of that array. Lots of ideas about that which I've never considered before because I never really looked at what 'the styledText' actually was (I thought it was another name for RTFText).

I might try to use that to implement styledText in xBuilder widgets.

Field text in HyperCard Simulator documents are literally made of HTML, each line is its own <div>.

[FourthWorld]

Most of those anomalies serve as reminders that htmlText isn't HTML.

It's similar, and some of it coincidentally renders well in a browser. But only coincidentally; it was designed to provide full-fidelity transfer of field contents in a plain text format for use within MetaCard.

The HTMLText is actually HTML, but it's only a subset of current HTMl, it's like working with old-school HTML v2.

3dbox and maybe a few other tags since aren't found in HTML.

Was that the goal of the HTMLText? If it was then that seems rather redundant when there's also 'the RTFText' and 'the StyleText', and plain old 'the text'.

Yes, as per the engine's inventor, htmlText was designed to provide full-fidelity transfer of field contents in a plain text format for use within MetaCard.

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.

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.

"the text" only includes the textual content, without any styling info at all.

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?).

It's a different beast than the printer language, and I don't know of any popular OS that's used it in years.

I see no reason to include any HTML capabilities other than working on HTML formatted text.

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.

XHTML was an experiment to fix that, but it came along too late for many to care, and JSON emerged causing interest in XML to wane, resulting in XHTML effectively dying a natural death a few years later.

It's been a while since I've tried, but I believe htmlText is more conformant with XML than HTML is, but don't quote me on that. MC didn't have the XML externals LC does anyway, so parsing meant have coding anyway.

But 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.

Field text in HyperCard Simulator documents are literally made of HTML, each line is its own <div>.

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. But once upon a time it might have saved $340k and nine years of payroll burn...

[OpenXTalkPaul]

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.

[FourthWorld]

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's a fine piece of work, potentially the struts of a bridge between the preinstalled scriptable rich-media engine from the dawn of GUIs, HyperCard, and the preinstalled scriptable rich-media engine of the present, the browser.