a "small" memory target is created, which maps only a subset
of fonts to memory for targets that have extremely limited amounts
of on-chip storage.
the main thing I'm not happy about with this change is that the
origin offset of the font table is hard-coded into the template,
but also, I'm not quite sure if there's a better way to do this
that doesn't make things unnecessarily complicated. The origin
offset *is* target specific, and the templates already
reference targets specifically in the config lists...so if this
were to be made more generic, the path you'd end up on is something
like parsing link.x files out of various configurations which seems
like an extreme amount of work for a constant that rarely changes.
So, it's a footgun, but one where mending the foot is several times
less effort than putting a safety on the footgun.
Regenerate the font files after adjusting the template to generate files
that will not get changed by rustfmt.
Signed-off-by: Sean Cross <sean@xobs.io>
Generate code that can be put through rustfmt without being altered.
This removes an issue where the font tables can be rearraged by simply
running `rustfmt` on the repository.
Signed-off-by: Sean Cross <sean@xobs.io>
Thanks to @samblenny for getting the ball rolling on this.
This commit adds a "tall" font face which is somewhere in betwee
the Regular size (12 pts) and 2x Small size (18 pts). This is
a compromise between text density and readability that has been
missing for some time from the UI.
The 32x32 glyph support is "hacked in", in that an extra flag
has been added to support this special case, rather than either
(a) making the library more generic (e.g. supporting 8x, 16x, 32x, 64x
glyphs) or (b) adding more metadata to the font libraries so that
the bitmap pattern is automatically associated with the font (right
now the parameters are set by hand in blitstr2/fonts.rs).
This is a violation of the "zero, one, many" principle in coding,
but I'm waiving that because (a) 64x glyphs don't make sense on
our system...you're not going to be creating posters and headlines
on this device (ha ha I say this today, tomorrow I will get a PR
for a poster editor app that absolutely needs 64x glyphs) and (b)
the font subsystem is, at least for now, a fairly mature and
well-tested code base so a minor futzing seems more appropriate
than ripping everything out.
The point at which things should be greatly refactored is when
we consider supporting right-to-left scripts or scripts that
require complex ligatures. But I think for now the system as
writ covers 80% of humanity's language needs acceptably
(but not perfectly).
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
previously blitstr2 is using usize for x/y coords, which means that
for layout purposes points could not go to the top or left boundary
without causing arithmetic overflow. Of course, you want to render
everything on-screen, but, as we have multi-line text with overflow
possibility, it's reasonable to be able to use negative coordinates
to locate text boxes that flow into the visible region.
This of course means that occassionally you can come out with
things like "negative widths", but even then, there can be reasonable
uses for this as an intermediate in calculations that ultimately
arrive at a positive result.
Really clear up the roles and structures of word wrapping.
Significantly, we have now figured out that the word wrapper
should be the word wrapper, and that the text bounds should
be computed by a text bounds computation.
Conflating flexible text bounds with word wrapping makes
the math really hard.
So, the word wrapper always works with a bounding area starting
at 0,0, and will wrap until it hits a Point designated as its
absolute max bounds.
The returned typeset block is referenced to 0,0, and then it
is shifted to the correct location by the rendering function.
This externalizes the computation of the final location plus
the rendering bounds to the outer functions that need to care
about this, thus simplifying the word wrapper significantly.
this just grafts in the new crate, while leaving the old crate
unscathed. once this is somewhat functional we'll excise the old
crate and reformat the loader for the "hard binary" image of
the fonts.
