Decker 1.54 is a major update that adds text-handing support for many non-English languages and numerous bugfixes and scripting enhancements.

DeckRoman

For pixel-perfect cross-platform fidelity, Decker implements its own text rendering routines and provides its own bitmapped fonts rather than depending on facilities inherited from your operating system or web browser. Previous versions of Decker only supported the displayable subset of text characters from 7-bit ASCII, which is sufficient for English, but most other languages- even those with a similar alphabet- need additional punctuation and diacritic marks.

Decker 1.54 introduces the DeckRoman character set, a carefully-designed Unicode subset which includes complete alphabets, diacritics, and punctuation for a variety of additional languages, including French, German, Spanish, Italian, Portuguese, Polish, Icelandic, Hungarian, Māori, and Romanian:

In case you're using a device or web browser which can't handle typing some of these characters manually, Decker's "Touch Input" keyboard has been expanded with an "alt" key:

Existing Decker fonts will still work, but will need revision if you'd like to support the full DeckRoman character set. To help you on your way, the "fontedit.deck" example has been reworked and expanded into the interactive guide All About Fonts, which includes an improved font editor with bulk-editing tools that can help you add a first draft of the required diacritic marks in minutes!

If your preferred language uses a non-Latin character set, the introduction of DeckRoman still offers some benefits and potential workarounds for representing text. Decker fonts can now contain up to 210 usable glyphs (versus 97 previously), which provides considerably more flexibility in adding custom alphabets without sacrificing the ASCII range used by Lil scripts. Japanese writing systems are not directly supported, but the inclusion of macronated vowels makes it possible, for example, to correctly represent "Romaji" transliterations.

I'd like to extend special thanks to Ahmwma for helping me extend most of the bitmap fonts shipped with Decker to support the full DeckRoman alphabet, ensuring that Deckbuilders have a strong foundation for using this new character set. "All About Fonts" also includes fonts generously provided to the Decker community by Olszoj.

New Features

• Introduced the read-only "image.bounds" attribute. Like "image.hist", this lazily computes useful information about the pixel content of the image. The result will be a "rect" dictionary giving a bounding box for nonzero pixels within the image, consisting of "pos", an (x,y) pair for the top left corner of the box and "size", a (width,height) pair giving its dimensions. This can be very useful for efficiently trimming whitespace from the edges of images or as part of certain kinds of collision detection.
• The Font/DA Mover dialog now indicates the number of populated glyphs of selected fonts, making it easier to determine at a glance whether a font supports the full DeckRoman alphabet.
• The deck.remove[] function may now be called upon an instance of the Patterns interface, which will reset the palette, animation sequences, and patterns to their defaults, for consistency with the behavior of the Font/DA Mover.
• The "in" operator now performs list-list comparisons using an internal hashmap, providing dramatic performance improvements for large columnar tests.
• The visual keyboard normally provided by entering "Touch Input" mode can now be temporarily summoned in any active Field via "Edit -> Keycaps..." or ctrl/cmd + K. This provides a convenient fallback method of entering any DeckRoman character if the user's system keyboard layout or web browser do not support typing them directly.
• The Deck Interface now exposes a read-only "deck.encoded" attribute which will produce a string representation of the deck (which happens to be precisely the text format of .deck files). This text format can be reconstituted into a new Deck Interface with the newdeck[] function. Decker can prompt the user to open and decode an existing deck file with read["deck"] and can prompt the user to save a Deck Interface as a .deck or .html export with write[deck]. This set of new features makes it possible to build Decks which read, manipulate, temporarily serialize, and write out modified decks, as was previously only possible via command-line Lilt scripts.
• More secret fun. :)

Fixes (Web):

• The Ply renderer for Twine no longer produces hard-wrapped text.
• Corrected inconsistent handling of unicode escapes when parsing %j/%J formatted JSON/LOVE strings.

Fixes (Native):

• Corrected crashes with danger.read[] and Lilt's read[] when the target file has insufficient permissions.
• Corrected Windows-specific crashes related to the %p parsing symbol; behavior of this feature is now more consistent with Web-decker.

Fixes (Both):

• Corrected inconsistent behavior and crashes when calling random[] in permutation mode with an empty source collection.
• Corrected subtle misbehavior when creating "Tight Selections" from a box selection in Decker.

Breaking Changes:

• Accessing Font glyphs via numeric indices now uses ASCII/DeckRoman indices instead of starting indices at the first displayable character (space; ASCII 32). This behavior is more internally consistent and will often simplify scripts by removing the need for an offset:

• Lilt no longer provides dedicated readdeck[] or writedeck[] functions; for improved consistency between Decker and Lilt, this functionality is now incorporated into the newdeck[], read[], and write[] functions. Note that as always the signatures of read[] and write[] in Lilt are different from Decker, as the former accept filesystem paths and the latter prompt the user for a file location and name.

In Lilt,

Happy deckbuilding, everyone!