Home | Reviews | GUIpedia | Forum | Fun500

HorvatMWhat's wrong with QML
While I like the idea of QML, the implementation could be much better.

1. The specification says that "QML is designed to be displayed on an 80 column display with 16 CGA colors and 16 CGA background colors", which limits it in several ways:

A. The 80 columns make it impossible to create a usable QML reader in an environment where for any reason it is impossible to provide 80 columns of text.
B. Similarly, if it is possible to provide more than 80 columns, the reader cannot take full advantage of the display width.
C. As with columns, not every environment can provide exactly 16 colors from the CGA text mode palette.

2. The PLAY ("*") tag is a joke; only QuickBASIC and a handful of other BASICs support it. (Not that I think playing music is a good thing.)

3. The specification should allow real graphics - this would allow graphical readers to make better use of a graphical environment, while text-only readers could still convert the graphics to text on the fly. Since graphics, as they are currently presented on QML pages, take a lot of space and rendering time, this would allow the user to turn off graphics (because readers would be able to easily recognize what is a graphic and what isn't) and therefore make pages load and render faster.

4. QML is "designed to be interpreted using the IBM extended ASCII character set", which obviously means code page 437. This means that pages and readers can only fully conform to the specification if they use exclusively code page 437, which not only cuts most of the non-USA world from QML (because only a handful of languages can be fully represented in that code page), it also makes it impossible to correctly render pages in environments which for any reason cannot (fully) support code page 437.

5. QML pages are, ironically, often larger than equivalent HTML pages, or at least that's what I noticed with my pages (which do not use "graphics"). This, I believe, is caused primarily by the break ("|") tag and because the page author has to explicitly color each hyperlink, preventing the user from knowing what is a hyperlink and what is not unless the page author specifically prepares the page. This also prevents users from being able to choose what they want hyperlinks to look like, preventing a standard look and feel for QML pages.

6. QML pages which mostly use black as their back color (which includes almost every QML page known) cannot sanely be printed on paper in color. This is in part because the specification says that the back color should be black unless explicitly specified otherwise, which often makes QML page authors use bright colors on black for their pages. While pages could have their back color set to white when printing, this would make certain colors (yellow, white, light gray, cyan) hard to see on paper. It would also potentially destroy text-rendered "graphics". I do not have a proposed solution to this problem, but I would like to add that I like the contrast of most QML pages (light colors on black) because they make on-screen reading easy and ergonomic.		2010-09-046:08 AM
BrandonRe:What's wrong with QML
HorvatM, a lot of the time you are overly critical of other people's work, this is one of those instances. With a little simple logic most of the issues can be fixed.
1A-Allow horizontal scrolling. Not idea, but a screen with under 80cols is going to limit you no matter what.
1B-If your space is bigger then do something else with the rest, for example a sidebar of bookmarks was concidered when making CQML3.
1C-Most modes however support 2 colors, so just ignore the color tags and draw in black and white, probably not what you are looking for, but will render pretty well.
2-It's known that the command is a joke, don't worry about it.
3-Maybe you should make an HTML browser, as it sounds like that's what you want.
4-idk
5-I suppose a $ + | command would help and would make sence. the problem is implement=ing support, as past browsers wouldn't support it. And links don't need to be colored, most QML browsers show links in some way.
6-Refer to 1C and print that way.		2010-09-049:49 AM
pharoahRe:What\'s wrong with QML
I thought it was worth responding to this thread, even though it's quite old, since I seem to still be de-facto "in control" of QML (although everyone is free to make their own markup languages if they'd like). Point by point: The 80 column requirement is about giving publishers some assurance of how their pages will render. As Brandon has said, scrolling is the solution for things like this (and its what they do on the web, as well). In fact, Trolly ran into a screen space issue when writing QMLView, which is why the scrollbar on the right hides itself (iirc). The other (albeit less attractive option) is to make the font smaller, which is what Brandon has done in CQML 3, and what I do on my android phone when I want to use PQML. If you have extra space, you've got two options. The first is to increase your font size, and the second is to put something else in that extra space. As a person with low vision, I'd prefer if you did the first, but of course it's up to you. If we're going to have any kind of color at all in QML, I think 16 colors is a fair lowest common denominator. Pretty much every graphics card made in the last 20 years can accomodate this number of colors, although often it's necessary to have the RGB values (see the source of icon or this paint thingy I made for a list). For those environments that can't provide all 16, I've built a few considerations into the spec which are intended to keep content from getting lost. The F and B tags, for example, are supposed to cue in QML readers that don't support background color rendering, so that if a page has a foreground color of 0 and a backrground of 15, the reader without background support can ignore the F and B tags, and will still render the foreground in a visible color. I know that Qeader is monochrome, although I haven't been able to really experience it (linux), but there is of course another monochrome QML reader, and that's PQML. PQML works fairly well, although it doesn't display ASCII art very nicely. The PLAY tag is explicitly optional in the spec. It's one of those little quirky things that I did for fun. Of course you don't have to implement it, or have it enabled in Qbrowse. The reason QML prohibits graphics is so that pages will render properly in text mode, since QML is fundamentally a text mode language, and is intended to promote the use of ASCII art. If you take a look at the icon QML page, you'll see that there's a wide variance in the way that graphics look when they're converted to QML. The lena picture looks fine, but the images after that get progressively worse, and the screenshot of Costa is barely recognizable. If you were to write a page that included graphics and hope that the QML reders would somehow convert them nicely, you'd more than likely end up presenting a bunch of unrecognizable garbage to text mode users. "On the fly" rendering tends to produce even worse results, since it has to be done in reasonable time. As a project, I recently wrote a PHP script that will convert an image to text using a lookup table. You can try it at the url http://en.wiki.tl/image/render.php. The default image is the mona lisa (which comes out fairly well), but you can set the URL parameter u to specify a (JPEG) image to try. The lookup tables size and generation time grows exponentially with the amount of fidelity you want to preserve in the original image colors. This version uses a 6 bit lookup table (64 different r, g, and b values), so its size is 3 * 64^3 bytes. You're right that I meant codepage 437 (although I didn't know what this was called until several months after writing the spec). In any case, you've exposed a fundamental problem with your criticism. If we use a more expansive character set (i.e. unicode), in your own words, it "makes it impossible to correctly render pages in environments which for any reason cannot (fully) support" that character set. On the other hand, if we decided to go with the almost universally supported US-ASCII 7 bit standard, you wouldn't have any diacritical characters or graphics characters at all. CP437 strikes a good balance, since it's natively supported in the BASICs we use, and has some nice graphical characters. I don't see a way to resolve both of the problems you've brought up at once, unfortunately. These are both good points. A text tag with a built in newline at the end, which I remember someone suggesting, would be a nice fix. The only concern is that older QML readers would then be missing a bunch of information on the page, since they wouldn't be showing textual content at all. Maybe it would be nice to repurpose the - tag, which is supported for text but next to useless now, for this use. I usually center things myself anyway, and I don't think we really need a tag that can only auto center a single line of text. I wouldn't be opposed to automatic hyperlink coloring (perhaps using a new tag that would set the default link color, and rendering pages without that tag in the old way). I'll put both of these things on my todo list to address. The link color fix is clearly much simpler, since it wouldn't break anything. To tell you the truth, explicitly coloring hyperlinks and download links has annoyed me for a while, but I haven't really thought about it too much. I like the retro aestheticj and the contrast of the black background pages, but I'd never thought of the eventuality of printing them out. Frankly, I've never had the urge to produce a hard copy of one of my incoherent Quickspace based ramblings, but there is certainly an issue there. I think that this is something that some future uber- QML reader will have to fix, by giving users the option of forcing a particular background color or printing in monochrome. Really, QML is intended to serve a specific niche purpose to the retro BASIC and DOS community, which is why it's tied to such dinosaur standards as EGA colors and CP437. I don't have any delusions about its chances of widespread adoption, since it's a toy intended for our (or perhaps only my) amusement. But it is a certain kind of toy, meant for certain things. You can play with it (write pages, readers, apps, propose some changes to the spec), but you can't eat it (make it graphical, able to embed video, interpret javascript, eat it) or hit your brother over the head with it (I can't think of an analogy, this is getting out of hand). Those activities are better suited to other standards. I'd award a virtual medal to anyone who could make a really usable Qbasic based HTML browser, but, since I can't, I screw around with QML. I'm hesitant to change the spec too much now only because I don't want to invalidate the work of people who have already written QML readers, or the work of people who have contributed content to quickspace. 		2011-03-155:25 PM
HorvatMRe:What\'s wrong with QML
As Brandon has said, scrolling is the solution for things like this

Scrolling is terrible, especially if the display is only a few columns short of 80.

In any case, you've exposed a fundamental problem with your criticism. If we use a more expansive character set (i.e. unicode), in your own words, it "makes it impossible to correctly render pages in environments which for any reason cannot (fully) support" that character set. [...] CP437 strikes a good balance, since it's natively supported in the BASICs we use, and has some nice graphical characters.

Hmmm, you're right. We could have QML readers convert encodings on the fly, but this would require bundling a ton of lookup tables with every reader. Or the specification can be changed to say "use any encoding, as long as it's 8-bit" since it's impossible for a program to (100% accurately) tell whether a page uses CP437 or not and "the BASICs we use" don't care about encodings; they just expect characters to be 8 bits wide.

Maybe it would be nice to repurpose the - tag, which is supported for text but next to useless now, for this use.

No! This would make pages look horrible on old readers; there would be whitespace after each line. We need a completely new tag. We could use the ampersand character, but ironically that character suggests appending the text rather than starting a new line for it.		2011-03-164:23 PM
pharoahRe:What\'s wrong with QML
Scrolling is terrible, especially if the display is only a few columns short of 80. I agree, but unless you've got a better idea, there's not much we can do about it. You have the same problem on the web, and the only solutions are to either draw the thing smaller or have horizontal scrolling. Certain things in QML will need to have a fixed width, in order to display properly. 80 columns seems like the best choice, since it's been the standard console width for about 30 years. No! This would make pages look horrible on old readers; there would be whitespace after each line. We need a completely new tag. We could use the ampersand character, but ironically that character suggests appending the text rather than starting a new line for it. Horvat, you haven't been reading your spec! The ampersand character is already defined as a tag. In any case, let me direct your attention to the entry for the - tag:
- - Center Prints a newline, then the text centered on the display line, then a newline to finish. This can be wrapped over several lines. If wrapping is not supported, the text should be printed as if it were a standard text tag, with leading and trailing newlines. So yes, the text has a newline before it, but that's the only issue. I'll admit that repurposing an old tag isn't the best solution, but the alternative is to have no text show up at all in older readers, which is clearly worse (at least from my POV) than a few blank lines here and there.
Fun fact: Did you know that the ampersand used to be considered a part of the alphabet? Children would recite "x, y, z, and per se and" at the end. 		2011-03-1710:23 AM
HorvatMRe:What\'s wrong with QML
I agree, but unless you've got a better idea, there's not much we can do about it.

OK. Don't break your lines manually. Let the reader do it; it's easier. If the reader breaks up words in half, it's not your fault, and they'll still be readable.

Horvat, you haven't been reading your spec! The ampersand character is already defined as a tag.

Oh, right, I forgot.

I'll admit that repurposing an old tag isn't the best solution, but the alternative is to have no text show up at all in older readers, which is clearly worse (at least from my POV) than a few blank lines here and there.

Or, someone can set up a converter service for those old readers to convert the text-and-break tag (which, I admit, is really only a problem when you're converting text files to QML or pasting code) to a $ and | pair. Be careful not to end up with feature creep though.

By the way, don't you think it's ironic that the specification is only available as a QML document? I know it's just a text file converted to QML, but it's not easy to spread the language if people need a reader to read the specification.

And, will we ever be able to see all the entries in CURSOR's database? I think it's amazing there are already 100 pages indexed but I don't know of that many.		2011-03-1711:26 AM
pharoahRe:What\'s wrong with QML
Don't break your lines manually. Let the reader do it; it's easier. If the reader breaks up words in half, it's not your fault, and they'll still be readable. That sounds fine, but it breaks down as soon as you have any content that isn't a bunch of paragraphs of text. You couldn't indent sections or have source code show up properly, and ASCII art (one of the main points of QML) would be pretty much impossible. Or, someone can set up a converter service for those old readers to convert the text-and-break tag (which, I admit, is really only a problem when you're converting text files to QML or pasting code) to a $ and | pair. Be careful not to end up with feature creep though. I'm assuming that someone would have to be me, and I'm not thrilled at the prospect of either writing a converter or having to use it to browse quickspace. Not only would it be unusable for QML readers without forms support (Qeader, for example), but it would also have to replace every link in the page with a link through the converter, in order to allow the person to continue browsing .This is how WebView works, and I find it cumbersome to work with. As you've pointed out, sometimes a consistent standard that works is better than an inconsistent standard that improves upon it. That's why I've been reluctant to add such a tag, although it has been proposed in the past as well. I'm trying to think of ways of doing it that will allow pages to degrade gracefully. By the way, don't you think it's ironic that the specification is only available as a QML document? I know it's just a text file converted to QML, but it's not easy to spread the language if people need a reader to read the specification. The text version has been on my server for a while, but nobody ever asked for it so I guess I never linked to it. Or, if you prefer, I made it just for you. I actually used this simple as hell converter that I wrote to make the QML version back in the day, in case that's useful to you. And, will we ever be able to see all the entries in CURSOR's database? I think it's amazing there are already 100 pages indexed but I don't know of that many. The cursor database is currently just a flat file. It's not the easiest read, but it has all the URLs in it. It shouldn't be too hard to write a simple script to parse it, if you're so inclined. The format is about as trivial as it gets. As an aside, have you considered getting AIM or Google Talk? You could save yourself a lot of time by criticizing me instantly :). 		2011-03-1712:32 PM

Other

2021 Brandon Cornell