Closed stevesims closed 6 months ago
If/when we add support for this, we will need to consider how this affects #119
Given that bitmap replacements will likely be intended to be of a particular size, it is likely that we should swap out the bitmap character replacement map, i.e. that this replacement map is tied to the selected font.
Definitely a good idea to make it possible to show several fonts at the same time (of different sizes). But one extra complication is the defined text window (VDU 28). Ideally you want the position & size of the text window (in terms of graphics pixels) to remain the same when you change to a font of different size while you have a text window defined.
Once fonts are stored in PSRAM, there should be no memory allocation issues when changing screen modes and you can have many screen fonts in memory at once.
Acorn added font selection using VDU 23,26
first on the Acorn Communicator, and then it came to Arthur 1.0 on the Archimedes.
https://www.beebwiki.mdfs.net/VDU_23#VDU_23.2C26_-_Select_font
fonts should be stored in buffers - which would thus ensure that they're stored in PSRAM. we will need a new command to mark a buffer as containing a font, providing dimensions for that font
using buffers also means that we already have commands that allow for the redefining of individual characters - we just need to document this and provide advice on how it works. the issue therefore of the current "redefine character" APIs only supporting 8x8 fonts is effectively solved. we will just need to ensure that if the current font is not 8x8 that those APIs are disabled
the text window issue essentially should be solved already - whilst the command to create text windows uses character coordinates, the window itself is internally stored using graphics coordinates. the new cursor behaviour system introduced in 2.7.x should also deal with issues around scrolling and text windows that aren't a clean (integer) multiple of the current font size
VDU 23,26
is a pretty ugly API - Acorn deprecated it with RISC OS, advising people instead to use the FontManager APIs. We should probably consider ignoring it and designing a completely new API
support for multiple fonts was implemented in #198. that work was continued in #200
this does not use VDU 23,26
, in part because it's an ugly API, but also it is incomplete as it does not seem to provide a mechanism to define a font.
multi-font API released in 2.8.0
further enhancements (such as supporting variable width fonts) can be tracked separately
The underlying text system in vdl-gl supports different fonts of different sizes. There are mechanisms provided to swap between different fonts.
Currently agon-vdp uses just a single font of a fixed size.
It would be nice to allow users to pick different fonts, of different sizes.
This idea leaves several open questions, such as how do user defined characters fit into this? Do re-defined characters get carried over when a different font is selected? (Probably not...) Do re-defined characters persist when returning back to the font they had been redefined in?