saymrwulf/xous-core
1
0
Fork 0
mirror of https://github.com/saymrwulf/xous-core.git synced 2026-11-08 04:56:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
xous-core/libs/blitstr2/codegen/config.json

148 lines
4 KiB
JSON
Raw Normal View History

initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
{
"comment": [
"Config for use with main.go. Before making changes here, see config_editor.rb."
],
initial attempt to move the font resources into the loader
2022-01-22 19:23:06 +00:00
"loadermod": [
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"../../../loader/src/fonts.rs"
initial attempt to move the font resources into the loader
2022-01-22 19:23:06 +00:00
],
"fontmap": [
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"../src/fontmap.rs"
initial attempt to move the font resources into the loader
2022-01-22 19:23:06 +00:00
],
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
"glyphSets": [
{
"name": "Emoji",
"sprites": "src_data/basic_emoji.png",
"size": 16,
"cols": 30,
"gutter": 2,
"border": 2,
"legal": "src_data/basic_emoji_legal.txt",
"index": "src_data/basic_emoji.codepoints",
"indexType": "txt-row-major",
"glyphTrim": "CJK",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/emoji.rs",
"loaderout": "../../../loader/src/fonts/emoji.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": true
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
{
"name": "zh",
"sprites": "src_data/hanzi.png",
"size": 16,
"cols": 30,
"gutter": 2,
"border": 2,
"legal": "src_data/hanzi_legal.txt",
"index": "src_data/hanzi.codepoints",
"indexType": "txt-row-major",
"glyphTrim": "CJK",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/zh.rs",
"loaderout": "../../../loader/src/fonts/zh.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": false
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
{
"name": "ja",
"sprites": "src_data/Izumi16.png",
"size": 16,
"cols": 30,
"gutter": 2,
"border": 2,
"legal": "src_data/izumi_legal.txt",
"index": "src_data/Izumi16.codepoints",
"indexType": "txt-row-major",
"glyphTrim": "CJK",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/ja.rs",
"loaderout": "../../../loader/src/fonts/ja.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": false
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
{
"name": "kr",
"sprites": "src_data/neodgm.png",
"size": 16,
"cols": 30,
"gutter": 2,
"border": 2,
"legal": "src_data/neodgm_legal.txt",
"index": "src_data/neodgm.codepoints",
"indexType": "txt-row-major",
"glyphTrim": "CJK",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/kr.rs",
"loaderout": "../../../loader/src/fonts/kr.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": false
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
{
"name": "Bold",
"sprites": "src_data/latin_bold.png",
"size": 15,
"cols": 16,
"gutter": 1,
"border": 1,
"legal": "src_data/chicago_legal.txt",
"index": "src_data/latin_index.json",
"indexType": "json-grid-coord",
"glyphTrim": "proportional",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/bold.rs",
"loaderout": "../../../loader/src/fonts/bold.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": true
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
{
"name": "Mono",
"sprites": "src_data/latin_mono.png",
"size": 15,
"cols": 16,
"gutter": 1,
"border": 1,
"legal": "src_data/courier_legal.txt",
"index": "src_data/latin_index.json",
"indexType": "json-grid-coord",
"glyphTrim": "monospace",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/mono.rs",
"loaderout": "../../../loader/src/fonts/mono.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": true
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
{
"name": "Regular",
"sprites": "src_data/latin_regular.png",
"size": 15,
"cols": 16,
"gutter": 1,
"border": 1,
"legal": "src_data/geneva_legal.txt",
"index": "src_data/latin_index.json",
"indexType": "json-grid-coord",
"glyphTrim": "proportional",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/regular.rs",
"loaderout": "../../../loader/src/fonts/regular.rs",
add small and regular font options doesn't break the mapping, makes code porting easier because the character resolution macros don't require adjustment.
2024-01-28 19:31:29 +00:00
"small": true
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
},
add Tall font face and support for 32x32 bitmaps 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).
2023-07-05 04:43:44 +00:00
{
"name": "Tall",
"sprites": "src_data/latin_tall.png",
"size": 19,
"cols": 30,
"gutter": 1,
"border": 1,
"legal": "src_data/helvetica_legal.txt",
"index": "src_data/latin_index.json",
"indexType": "json-grid-coord",
"glyphTrim": "proportional",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/tall.rs",
"loaderout": "../../../loader/src/fonts/tall.rs",
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
"small": true
add Tall font face and support for 32x32 bitmaps 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).
2023-07-05 04:43:44 +00:00
},
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
{
"name": "Small",
"sprites": "src_data/latin_small.png",
"size": 12,
"cols": 16,
"gutter": 1,
"border": 1,
"legal": "src_data/geneva_legal.txt",
"index": "src_data/latin_index.json",
"indexType": "json-grid-coord",
"glyphTrim": "proportional",
move blitstr2 to its own library this allows us to share font data between platforms without replicating the code base
2025-02-17 10:24:39 +00:00
"rustout": "../src/fonts/small.rs",
"loaderout": "../../../loader/src/fonts/small.rs",
add small and regular font options doesn't break the mapping, makes code porting easier because the character resolution macros don't require adjustment.
2024-01-28 19:31:29 +00:00
"small": true
initial attempt to integrate blitstr2 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.
2022-01-18 19:29:53 +00:00
}
]
add target hooks to font generation (part I) 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.
2024-01-27 18:11:09 +00:00
}
Reference in a new issue Copy permalink