PIGLet File Format Specifications Copyright 2007, Chuc McGuire The file format is basically the same for both fonts and graphics, with the sole exception that graphics files use encryption. So, I'll begin by describing the format for fonts. Each "character" of a given font set is stored in a single attribute (e.g., a font which only contains the 26 capital letters of the American English alphabet would require 26 attributes, one for each character). Within a single such attribute is a long string of mostly numbers (possibly some letters for certain custom fonts). I suppose the best way to explain this is via illustration. So, let's use the Big Chief font's capital A (ascii character value 65, or 065). When displayed, it looks like this... ________     __       / |  ---/__|-   /   |  _/____|_ But, when it's acquired from a textfile prepared for the FIGLet program (figlet.org), it looks like this... ________@     __  @     / | @ ---/__|-@   /   | @ _/____|_@@ The conversion from this format into something that can be handled by softcode is, although not difficult, somewhat tedious. First, I convert all of the 'spaces' into some character which won't be stripped or squished by the MUSH parser, such as a dollar sign ($), which the FIGLet program uses, or (my preference) the 'double S' (aka 'section mark'): § The result then looks something like this... ________@ §§§§__§§@ §§§§/§|§@ ---/__|-@ §§/§§§|§@ _/____|_@@ Next, through a series of edits, I take advantage of the 'FIGLet' format's use of @ symbols in the plaintext files to insert attribute and object code for the installer. The above '§-filled' data is initially installed as individual attributes (per line of the display); then, after all lines have been installed, the characters are converted into space separated lists of comma-prefixed ascii values, and the lines are condensed into a |-delimited list... all of which is piled into one attribute. (Details of this process are covered in another document.) (NOTE: The double-s characters are converted to 'non-breaking spaces' -- ascii value: 160) Something like this... &FONT`BIGCHEIF`065 = ,95 ,95 ,95 ,95 ,95 ,95 ,95 ,95|,160 ,160 ,160 ,160 ,95 ,95 ,160 ,160|,160 ,160 ,160 ,160 ,47 ,160 ,124 ,160|,45 ,45 ,45 ,47 ,95 ,95 ,124 ,45|,160 ,160 ,47 ,160 ,160 ,160 ,124 ,160|,95 ,47 ,95 ,95 ,95 ,95 ,124 ,95|,160 ,160 ,160 ,160 ,160 ,160 ,160 ,160|,160 ,160 ,160 ,160 ,160 ,160 ,160 ,160 The purpose for having comma-prefixed characters is so that, if you decide that some portions of an image need to be a specific fixed color, you can (using the Illustrator or, possibly via a mass @edit) insert those specific ansi color values into the actual formatted file. For example, if you wanted the 'non-letter' portions of a Big Chief character -- i.e., the 'tablet lines' -- to be always 'hilited blue' on your MUSH, you could make that happen by placing bh in front of all the appropriate (,) items in the file. Such as the top row of underscores (,95) would become bh-prefixed (bh,95), the middle row of hyphens (,45) would, as well (bh,45), etc. Then, the softcode which displays these would apply user specified ansi codes before the ones in your custom file, allowing the custom file's specific ANSI codes to supercede those of the user. Continuing our above example, if someone specified ~let(bigchief:Br,A), the end result would be a red 'A' on a blue background, with blue-hilited 'tablet lines (i.e., Bbh for the tablet lines, and Br for the letter). That's pretty much all there is to it. (When I convert a font from the plaintext FIGLet flatfile into this PIGLet format, I do the aforementioned edits as a mass process on the entire font set, of course.) Graphic (ASCII Art) files are exactly the same with one exception. There is an extra step to the process. Once an image has been converted from plaintext into this format, the entire data set is encrypted using *ALL* contributing artists credits as the password for that encryption... and all of that credit is placed at the beginning of the file, resulting in this abbreviated data structure. &AART`IMAGE1 =Joe Artist, Sally Colorizer, Terry Animator| Then, the code for displaying graphics is identical to the code for displaying fonts, with the exception that it first goes through a decryption process. Because of the potential for derivative works, this code is written under the assumption that evolutionary works -- e.g., B&W ascii drawing by Artist1, colorized by Artist2, animated by Artist3 -- include cumulative rights management. For example: If... * Artist1 releases an ASCII drawing to the public with the only stipulation being credit retention in some form (i.e., don't ever completely strip me of credit for my unique creation). * Artist2 adds ANSI color Artist1's image and releases his to the public with basically the same stipulation as ArtistA. Then... * Artist3 animates the image by creating a sequence of images based on Artist2's colorized version of Artist1's original drawing. Based on the very minimal conditions of Artist1 and Artist2's usage stiputations, Artist3 can release his work with the stipulation that its use be restricted to use only on GameZ. That is, if neither 1 nor 2 explicitly forbid some use, it is assumed to be allowed (the law may choose to differ with this, -- until then, this is assumed in order to encourage exploration of derivative open development avenues). If, however, Artist2 had added an additional stipulation that any use of the colorized version (as is, or derivatives) cannot be used for commercial purposes; and GameZ was [part of] a commercial (i.e., not legally classified as 'not for profit') entity; then Artist3's derivative work could not be used on GameZ (nor any other commercially operated game) at all. That is to say... Unless otherwise prohibited by a previous developer or contributor's restriction, a right is assumed to exist. And prior restrictions cannot be usurped by any subsequent developer or contributor's usage stipulation. Restrictions are sequentially cumulative.