Add a dlo-based layout callback for use with lhp.
If lhp_dl_render() is used as the Lws Html/CSS parser callback, it
produces a display_list representation of the Html as DLOs, referencing the
appropriate CSS to drive the layout as best it can.
The display list can be rasterized on to an lws_display using the display's
state object
lds->disp->blit(lds, (uint8_t *)&dl, &box);
Introduce a very lightweight html5 + css2.1+ stateful stream parser, along
the same lines as the lws json and cbor ones.
This is interesting primarily because of just how low-resource it is for
modest css + html, it uses an lwsac to hold the entirity of the css in
memory at once but the html is parsed in chunks without any need to keep
previous chunks around (chunks may be as small as 1 byte).
A user callback receives element entry and exit callbacks with payload and
all attributes parsed out, CSS related to the active element stack is
parsed to provide a list of active css attributes, which takes heap for the
duration of the parsing.
In effect this provides rich information about the html and css state to
the callback, which has the job of producing the layout in a user-defined
way.
As such, there is no DOM in memory at one time, there is only a stack of
active elements like <html><body><div>xxx with their associated attributes
(like class). So as it is, it does not support DOM modification such as
JS changing elements after parsing, although elements with interesting IDs
could be kept around by the callback. There is a corresponding tiny and
relatively flat heap usage regardless of html size.
Default CSS is specified as recommended in the CSS 2.1 standard.
Inline <style></style> elements are supported, but not pre-html5 style= in
element attributes, since these are incompatible with strict CSP.
What the attributes should mean on your system, eg, font-size, font-family
etc is left for the user callback to decide, along with how to lay out the
items using the CSS attributes, and render them.
Fixed point 32.32 constants are used (fraction expressed at parts in 100M)
instead of floating point.
If you have presentation needs, even on a constrained display on a
constrained microcontroller, this makes it feasible to use standardized
markup and styling instead of roll your own.
This adds an optional lws VFS layer that exposes the named dlo object
registry. So you can register a blob like a JPG named "my.jpg", and
access it on the vfs as, eg, /dlofs/my.jpg (or file:///dlofs/my.jpg
if using the SS file:// support for VFS namespace).
This adds optional display list support to lws_display, using DLOs (Display
List Objects). DLOs for rectangle / rounded rectangle (with circle as the
degenerate case), PNGs, JPEG and compressed, antialiased bitmapped fonts
and text primitives are provided.
Logical DLOs are instantiated on heap and listed into an lws_display_list
owner, DLOs handle attributes like position, bounding box, colour +
opacity, and local error diffusion backing buffer.
When the display list is complete, it can be rasterized a line at a time,
with scoped error diffusion resolved, such that no allocation for the
framebuffer is required at any point. DLOs are freed as the rasterization
moves beyond their bounding box.
Adds a platform registry binding names and other metadata to lws_display
fonts / PNGs / JPEGs. Provides registration, destruction and best match
selection apis.
