It would be nice for longer data-structures when one can omit bits that belong to the same group.
My idea would be to add e.g. gap: 10 to a range and then the middle 10 bits are skipped and "replaced" by dashed/dotted lines at top and bottom.
Would you say this is something achievable or does it require bigger changes? Are you open for PRs? (but not sure if I will be able to get it working)
I started exploring the code and thought starting with removing the bits field and autocalculate it. As far as I understand it the code relies heavily on absolute coordinates respective at least the functions to-real-i(i) and to-bit-i(real-i) need to be adjusted.
It would be nice for longer data-structures when one can omit bits that belong to the same group.
My idea would be to add e.g. `gap: 10` to a range and then the middle 10 bits are skipped and "replaced" by dashed/dotted lines at top and bottom.
Would you say this is something achievable or does it require bigger changes? Are you open for PRs? (but not sure if I will be able to get it working)
I started exploring the code and thought starting with removing the `bits` field and autocalculate it. As far as I understand it the code relies heavily on absolute coordinates respective at least the functions `to-real-i(i)` and `to-bit-i(real-i)` need to be adjusted.
That is a great idea ! And yes I am open to PRs 👍
It's definitely something achievable, but it does indeed have some implication since - as you've mentioned - many elements are placed absolutely.
I'll also try and take a look. Feel free to ask if some parts of the code are not clear
That is a great idea ! And yes I am open to PRs 👍
It's definitely something achievable, but it does indeed have some implication since - as you've mentioned - many elements are placed absolutely.
I'll also try and take a look. Feel free to ask if some parts of the code are not clear
HEL
added the enhancement label 2025-05-13 09:34:52 +00:00
Klagarge
added a new dependency 2025-05-13 10:03:12 +00:00
Is it ok for you, when the schema definition is changed by code or should it always stay the original one?
I'm thinking about auto-calculating a few helpernumbers (e.g. the "structure.main.bits" or a new variable "structure.main.total-gaps") and would like to know whether you are fine when I add them to the schema or whether I should use extra variables.
One general question:
Is it ok for you, when the schema definition is changed by code or should it always stay the original one?
I'm thinking about auto-calculating a few helpernumbers (e.g. the "structure.main.bits" or a new variable "structure.main.total-gaps") and would like to know whether you are fine when I add them to the schema or whether I should use extra variables.
It's okay for me to modify the schema internally
It is somehow already the case in structure.load for example, where some properties are extracted and formatted from the input data
It's okay for me to modify the schema internally
It is somehow already the case in `structure.load` for example, where some properties are extracted and formatted from the input data
https://git.kb28.ch/HEL/rivet-typst/src/commit/3e74ad15ee68885b0ac729786418de9a3d6e36e7/src/structure.typ#L18-L52
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
It would be nice for longer data-structures when one can omit bits that belong to the same group.
My idea would be to add e.g.
gap: 10to a range and then the middle 10 bits are skipped and "replaced" by dashed/dotted lines at top and bottom.Would you say this is something achievable or does it require bigger changes? Are you open for PRs? (but not sure if I will be able to get it working)
I started exploring the code and thought starting with removing the
bitsfield and autocalculate it. As far as I understand it the code relies heavily on absolute coordinates respective at least the functionsto-real-i(i)andto-bit-i(real-i)need to be adjusted.That is a great idea ! And yes I am open to PRs 👍
It's definitely something achievable, but it does indeed have some implication since - as you've mentioned - many elements are placed absolutely.
I'll also try and take a look. Feel free to ask if some parts of the code are not clear
One general question:
Is it ok for you, when the schema definition is changed by code or should it always stay the original one?
I'm thinking about auto-calculating a few helpernumbers (e.g. the "structure.main.bits" or a new variable "structure.main.total-gaps") and would like to know whether you are fine when I add them to the schema or whether I should use extra variables.
It's okay for me to modify the schema internally
It is somehow already the case in
structure.loadfor example, where some properties are extracted and formatted from the input data