PAML Notation Specs?

[tajmone]

Is there a document with the PAML syntax specification?

[joedf]

Whoops! Just saw this now... I really only have examples for now https://github.com/joedf/PixelArtMarkupLanguage/blob/master/Paml_Viewer/Samples

Pikachu: https://github.com/joedf/PixelArtMarkupLanguage/blob/master/Paml_Viewer/Samples/Pikachu.paml

Pretty straight forward, a space is considered a "transparent" pixel. However, I really think this project should be rewritten. I was experimenting with markup-ish language of my own at the time.

[joedf]

I will possibly write a javascript version of this, if anything.

[tajmone]

Thanks!

I will possibly write a javascript version of this, if anything.

If you do, please give me a buzz! Keep up the good work.

[joedf]

Current test https://github.com/joedf/PixelArtMarkupLanguage/tree/master/web

Draws in both the html body and the js-console.

[tajmone]

Thanks for the update. I've managed to see it via HTMLLivePreview, and it's really nice:

http://htmlpreview.github.io/?https://github.com/joedf/PixelArtMarkupLanguage/blob/master/web/index.html

I'll be posting about it on the Cosmigo Pro Motion forum to keep the Pixel Art artists therein updated on this!

[tajmone]

Posted:

• https://community.cosmigo.com/t/paml-pixel-art-markup-language/484

I was asking about PAML specs because I was tinkering with the idea of creating a PAML export plugin for Pro Motion. It would be quite nice to be able to save Pixel Art works directly to a web usable format — and the example you provided is really nice.

[joedf]

Nice to see interest in this! I started this because I wanted a text-edible, human readable, pixel art format. Added GitHub Pages: http://joedf.github.io/PixelArtMarkupLanguage/web

[tajmone]

I see a good potential in PAML for it could serve as human readable middle-format in many cross-graphics contexts. For example, to export pixel art to ANSI Art in applications like BBSs, MUDs/MUSHes, as well as emails and even Voxel art. Also, it could be employed over a variety of text-only protocols, which is quite cool. Pixel Art fits well in the retro-scene, so chances are that whoever still appreciates ANSI Art, BBSs, MUDs, etc., is going to appreciate pixel art too, and in those old standards text-only protocols are still pretty much the standard.

The format seems intuitive (html-like tags, ; for comments, etc.), but if you manage to jot down some specs details it would be a good idea, just to avoid the profileration of dissonant versions (like it happened with markdown). E.g., specify the valid range of employable pixel representation characters, if files should be encoded in Ascii or UTF-8 (and, for the latter, if BOM should be allowable, etc.), whether any EOL characters could be valid (CRLF vs LF), can Tabs be used or not, etc.

When markdown came out, no one really expected that it would eventually boom so fast, and ultimately we ended up having so many markdown flavors that the portability became soon a problem.

[joedf]

I don't know what BBSs, MUDs/MUSHes stand for, but you are right. I should start defining specs.

[joedf]

Started here: https://github.com/joedf/PixelArtMarkupLanguage/blob/master/specifications.md

[tajmone]

Excellent! Thanks a lot @joedf.

As for the colors names listed in htmlcolors.h, are these names taken from the CSS standard or are they arbitrary chosen? Apps will need to handle those correctly.

Still regarding colors, besides the six numbers hex notation (eg #ffffff), should also the three-number notation be supported (eg #fff)? Colors definitions is a potential area where implementors might be tempted to expand upon, with the risk of having incompatible standards (from accepting RGB colors notation to Alpha values, etc.).

---

PS:

I don't know what BBSs, MUDs/MUSHes stand for

Those were (but somehow still are alive) Bulleting Boards Systems, and MUDs/MUSHes were the first generations of online multiplayer games over the Internet during the 80-90s, all text based and relying on Ascii/ANSI art for graphics. That was when home computers where first starting to enter people's homes — when no one dreamed that in 20 years times 1.5Ghz processors would be considered "dinousars", but instead people where overwhelmed by graphics with 320×200 resolution and a 16 colors palette.

It was the era of text adventures, when immagination was still the main graphic hardware, allowing you to see beauty in 16x16 pixels images or Ascii characters graphics. Text was dominant, and so were "2nd person thinker games", which soon were replaced by GPU cards and "1st person shooters" requiring little imaginative participation.

• http://www.bbsdocumentary.com/
• http://www.getlamp.com/

Connecting to a BBS required a land-line modem (noisy and veeeery slow), and just to connect to the internet you might have to try dialing your provider number over and over again, for over an hour (if you were lucky), in order to find a non-busy line (a provider with 100 users and 20 line was considerd a "big" ISP then). You would buy special gadgets to plug in your phone, so that when the line was busy the number would be dialed over and over again. Back then, sending a single line of text to users in the BBS or MUD would entail seconds of delay ("real time" was an approximate concept). Also, many IPS would automatically cut off your line after 1 hour connection, to give other users a chance to connect; and when you were connected to the Internet no one in the household could use the phone (you know, dishes and shoes fyling across rooms, and that kind of anger stuff).

And of course ... you'd have to pay monthly fees to be part of a BBS, with membership card and all! Seach engines came later on, and the internet was a small and unexplored land, with gopher and telnet being the mainstream protocols.

Yet, everything about computers seemed truely magic. It was something new, unheard of in the domestic realm; the whole idea that computers could be used for fun instead of rocket-science was revolutionary. Of course, today much of the magic has faded away, and children walk around with 8-core RISC processors in their pockets. Today the idea of having to work within 64Kb of RAM constraints is unthinkable, and generally programming is not so much about code optimization and trying to squeeze information tight in every single bit available. Today RAM and storage are cheap and we can get away with wreckless code and storage waste. In the BBS era loading big Ascii Art would come at the cost of higher phone bills.

Pixel Art is obviously still strongly tied to that era and, although the beauty of seeing Pixel Art on CRT monitors is a thing of the past, the good standards of that age are still in use (think of Electronic Arts' IFF 85, which is still used in AIFF today).

[joedf]

very nice insight! I have yet to add color and symbol rules, etc. That said, the idea is to support whatever color css\html supports. Those colors were taken from the css standards. So I don't why not support #fff or even rgba(255,255,255,1.0), etc. The great thing about the javascript version is that I can let the browser handle that. I could use Node.js or electron to quickly launch it into a crossplatform CLI-application, but I do like the idea of a reusable DLL.

[tajmone]

Those colors were taken from the css standards.

I had though so, but wasn't sure about it.

Supporting alpha colors might not add any benefit right now if PAML is intended for presenting single sprites on user defined background color, but maybe in the future it might find applications. In that case, the 8 digits hex notation might be worth too (#rrggbbaa).

My worry with the rgba() and rgba() notation is that it might add some parsing complexity in RegEx based applications, possibly with little advantage over the hex notation. But I might be wrong on this.

The great thing about the javascript version is that I can let the browser handle that. I could use Node.js or electron to quickly launch it into a crossplatform CLI-application, but I do like the idea of a reusable DLL.

Yes, browser support is a good added value, also because it's going to work in WebBrowser controls too (WebKit, etc.). Electron could indeed provide a good viewer for PAML, as well a GUI tool for conversion, etc. The only grudge I have with Electron is that often you end up with multiple copies of it, one for every application.

Interactive Fiction adventures, which have been using dedicated file formats and lightweight cross platform virtual machines since the 80's, in the last years have seen a new wave of Electron-based adventures created with new Node.js authroing tools. The result is that during the yearly IF contests, where usually you could download all the contest entries in a Zip archive of a few hundred Kbs, now downloads are over 100Mb in size, due to multiple adventures being distributed with the whole Electron package (while the adventure file is still a few Kbs in size, the Electron binaries are something like 900% the adventure size). This led to an expected bloat in the IF Archive which stores all the adventures published since the 70's, which has almost doubled in size since the Electron authoring tools have come out (and probably will be facing unexpected storage problems soon).

Somehow, it's a problem that goes beyond mere size, and often is perceived of a violation of the unspoken rules of what old-skool retro gaming was all about. How comes that adventures that have over 800 locations to visit, and can take up to 5 monthes to play till the end, are only 100Kb in size, while new adventures which are short (half hour teasers) and have 20 locations now weigh over 80Mb? All the efforts to create small footprint Virtual Machines that can work on very low-ram computers, and then we see an invasion of adventures wrecklessly stomping over memory and storage.

Another issue I have with Chromium/CEF based frameworks are the concerns about privacy and data mining.

Electron/Chromium vs Sciter

A small footprint alternative to Electron is Sciter:

https://sciter.com/

Although not open source, it can be freely used in open source projects. It ships as a single shared library, available for many platforms, and can basically do everything Chromium does, but also interface with binary applications.

[joedf]

Interesting... Also, good point. I am not sure if half transparent pixels would be useful for this art form... Currently the C version only explicitly supports the HTML named colors e.g. CornflowerBlue and 6-digit hexadecimal RGB e.g. #FFFFFF.

[tajmone]

I'm currently working on some proof of concept plugins for the Pixel Art editing software Pro Motion NG:

• https://community.cosmigo.com/t/file-i-o-plugins-a-language-agnostic-guide/486

My intention was to build as a demo plugin a PAML export filter — this being one of the reasons why I'm asking about tech specs, since I'll have to hardcode color names, EOL chars, etc.

Although the plugin is going to be mainly a proof of concept and an example of how to implement plugins in various languages, I think it's going to be quite cool to have a Pixel-Art dedicated editor that can export PAML files.

At save time, a dialog will popup and ask the user about the pixel scale ratio, since this setting can't be stored in the images or deduced from them.

Probably having an inverse filter wouldn't be quite as useful right now, partly due to the pixel scale ratio (which would require restoring original 1-1 pixel), but also because starting from a PAML source the CLI tool is an easy way to obtain a PNG image. But you never know.

Surely, converting from image to PAML is the most appetizing feature.

I'm really interested in the potentials of this standard. I could have just created a plugin that exports HTML pages (like the PAML cli tool does), but the idea of a dedicated and human readable text-format is quite exciting, for it opens the doors to all of sort of (yet unimagined) uses. So I'm curious to see how it will take off.

PS: I did notice that the cli tool wasn't converting to PNG, but I thought that it was Windows antivirus which was deleting the images after they were created (it often does this, and it seems to dislike some files produced by running processes). Antiviruses are such a pain, especially since they see any usage of UPX as a malware (99% of the alerts are just false positive about UPX packing, and if you unpack the file they go away). I had stopped using AutoIt and AHK because of the strong (and unfair) penalties in using UPX. Sad.

[tajmone]

Valid Color Indices Chars?

While sketching the image to PAML export filter, I'm realizing that the spec might also need to establish which are the characters which are employable to represent a color index in the text bitmpap.

Assuming that 256 palettes are supported, then Ascii would not provide sufficient displayable character to cover them all. My guess is that a roof of max 64 colors/chars might be a good idea even if UTF-8 was to be mandatory supported. Non Ascii-chars might be difficoult to use in manual edit (and require keyboard alt codes), some UTF-8 chars might end up being badly shown in various tools (cli tools output, diffs, etc.).

Sure, 256 color palettes is a desirable goal, but although they might seem very few colors according to today graphics standards, they are actually a lot of colors in the realm of Pixel Art, where 64 colors would cover a good deal of images.

The PAML specs should be clear on similar issues so that portability of PMAL files isn't broken. Third party apps could always reduce colors on the fly, bringing the palette colors down to the prescribed limit by using some color similarity algorithm (CIE dE2000, etc.).

An export filter would have to come up with some system for deciding which chars to use for each color. Probably a queu or stack would be a good approach, where the nicest looking characters are made available first, and less appealing ones last (eg. ., #, @ ... A, B ...). The usable chars could then be popped on demand.

Some characters are likely to be illegal to use. Eg , which is used as a color separator, and other obvious ones like space, EOL, and all the control chars. Other chars are less obvious, eg. the comment delimiter ;, which could actually be used without ambiguity in the bitmap representation (but at the cost or rigorous checks of the columns width, which could account for extra comments on a pixels line).

The problem here is likely to be that different approaches could be taken to parsing the textual bitmap — eg. loopig through the matrix char by char, or using a RegExs approach instead, and so on. This is an area where implementation specific issues could easily creep in.

The difficoult thing is always finding a balance between specs safety and simplicity of use. Too many strict rules could deterr people away, but uncovered aspects could very quickly lead to the profileration of incompatible implementations (see the browser wars, markdown, etc.).

Spec Version Field

IMO, this also indicates that PAML files should have a spec revision number field, to allow apps to know which was the standard used for the file creation. Beside a version number, an extra field could be used to indicate wether the standard is being used strict, loose or experimental, which might leave some room for exploring experimental features and warn apps about images created with non strict standards (eg. to accomodate special needs).

The strict/loose/experimental distinction would allow to restrict the mandatory features of the spec, while still leaving the door open to more advanced features (for which third party apps support is not guaranteed).

Alpha colors could, for example, be labeled as experimental in v1.0.0 of the spec, allowing end users and developers to test edge cases and current limits, and when enough feedback is available it could be decided if Alpha support should be included in v1.1.0/strict, or in loose, or become permanently experimental.

Specs can take years to be ultimately defined, and allowing users and developers enough time to reality-test it is always preferable. Ultimately, a spec should grow around users needs, not the other way around; and as far as PAML goes we're dealing with a cross-realm standard which also bridges the world of graphics with that of Ascii/ANSI text, so it's difficoult to predict what uses and needs are ahead. But some aspects, like those being discussed here, might require immediate adressing.

Anyhow, as long as developers know that there is a spec of reference and a drafting process going on, chances are that feedback, proposals and discussions will prevent wild proliferation of standard deviations.

[joedf]

Very good points made. , and ; are illegal characters for now. I have thought about what characters would be used above the limit of ASCII... Then I thought, how complex would the artwork have to be to have such a high variation, clearly PAML might never reach 16 million in it's current form. That said maybe it's good that we allow weird unicode characters, perhaps even emojis. Sure they made be hard to type at first, but the potential is there to support these, macros can be made, special keyboards, etc.

For versioning, maybe I should add that as an attribute in the paml tag, something like this? <paml version="1.0.0.0" encoding="UTF-8" type="strict">

[tajmone]

For versioning, maybe I should add that as an attribute in the paml tag, something like this? <paml version="1.0.0.0" encoding="UTF-8" type="strict">

That would be good and leave room for future updated. Maybe for the version number I'd stick to 1.0.0 and propose adopting SemVer 2.0:

• https://semver.org/

SemVer is well known and already adopted by many languages, so there are many validation tools libraries in the wild (NPM, Ruby, Python, etc.). It also allows pre-releases and build metadata, so any application supporting PAML would know when they are handling files created with experimental or prereleases version of the standard.

clearly PAML might never reach 16 million in it's current form.

I agree, it wouldn't make sense to enter the realm of True Color or, indeed, anything above 256 color palettes (256 colors being already a challenge in terms of human readable characters to represent them all).

Ideally, the range of usable characters should be defined, as it would be good to allow characters that show up properly in monospaced fonts, without breaking alignment (ie wider than usual glyphs), and that most fonts will be able to represent them univoquosly (without fallback glyphs substitutions). I'm sure that there are some Unicode subsets which are common enough to be represented on most monotype free fonts; probably in this context it's worth considering what the average font used in code/text editors will include.

[joedf]

I like that. Good points made.

[tajmone]

Thanks for the spec update!

BTW, I haven't forgotten the PAML export plugin project I had in mind, it's just that I'm facing some problems with the plugin API documentation, which seems incorrect (or old):

• https://community.cosmigo.com/t/file-i-o-plugins-a-language-agnostic-guide/486/2?u=tajmone

So I'm waiting for some answers on how to correctly interface to the application, but since that app is closed source I'm kind of stuck until I get some directions from its author.

[tajmone]

Good news, the documentation on PM NG plugins interface has been updated today, so the incongruencies on error handling are now clarified:

• https://community.cosmigo.com/t/file-i-o-plugins-a-language-agnostic-guide/486/3
• https://www.cosmigo.com/pixel_animation_software/plugins/developer-interface

So, now that I have all the required info, hopefully I'll find a free time slot in the upcoming week to try implementing a proof of concept plugin to save images to PAML.

[joedf]

Oh cool! This is exciting to see my old little side-project to potentially bloom into something. 😄