When using depends on and start > 0 the bits no longer align. #12

New Issue

taylorh140 · 2025-09-22T16:39:43Z

taylorh140 commented

2025-09-22 16:39:43 +00:00

Title says it all really. but it would be rude to not leave a visual example.

#let Test = (
  structures: (
    main: (
      bits: 32,
      start: 1,
      ranges: (
        "32": (
          name: "P",
          description: "Parity (odd)",
        ),
        "31-30": (
          name: "SSM",
        ),
        "9-29": (
          name: "Data",
          depends-on: "31-30",
          values: (
            "11": (
              structure: "problem",
              description: "Good",
            ),
          ),
        ),
        "1-8": (
          name: "Label",
          description: "Why?",
        ),
      ),
    ),
    "problem": (
      bits: 21,
      start: 9,
      ranges: (),
    ),
  ),
)

#schema.render(schema.load(Test), config: cfg )

Title says it all really. but it would be rude to not leave a visual example. ```typst #let Test = ( structures: ( main: ( bits: 32, start: 1, ranges: ( "32": ( name: "P", description: "Parity (odd)", ), "31-30": ( name: "SSM", ), "9-29": ( name: "Data", depends-on: "31-30", values: ( "11": ( structure: "problem", description: "Good", ), ), ), "1-8": ( name: "Label", description: "Why?", ), ), ), "problem": ( bits: 21, start: 9, ranges: (), ), ), ) #schema.render(schema.load(Test), config: cfg ) ``` <img width="967" alt="image.png" src="attachments/700ea13d-0c10-4952-95e2-beeeae9bc965">

image.png

25 KiB

taylorh140 commented

2025-09-22 16:43:45 +00:00

And not to pile on, but it would be nice too to get finer grain adjustment for the sub-structures like and depends on. such as the horizontal position of the arrow going down from data, as it often cuts through labels. So, if there are more hidden gems 😍.

HEL added the

bug

label 2025-09-22 18:01:36 +00:00

HEL commented

2025-09-22 18:09:58 +00:00

First of all, thank you for your feedback 👍
It does seems like the start offset messes up dependencies

Regarding your example, how should the horizontal arrow be drawn, since both the value and alternative sub-structures are right next to each other ?

such as the horizontal position of the arrow going down from data, as it often cuts through labels

It is indeed quite unfortunate in most cases. Do you have an idea of the kind of parameter I could add to help users fix this issue ? Or maybe example diagrams in which it is better handled ?
In general, Rivet doesn't give the user much freedom in the layout of structures and bits. This helped keeping the package simple, but it can be quite restrictive. I am welcome to suggestions on ways to improve the API or even PRs

First of all, thank you for your feedback 👍 It does seems like the start offset messes up dependencies Regarding your example, how should the horizontal arrow be drawn, since both the value and alternative sub-structures are right next to each other ? > such as the horizontal position of the arrow going down from data, as it often cuts through labels It is indeed quite unfortunate in most cases. Do you have an idea of the kind of parameter I could add to help users fix this issue ? Or maybe example diagrams in which it is better handled ? In general, Rivet doesn't give the user much freedom in the layout of structures and bits. This helped keeping the package simple, but it can be quite restrictive. I am welcome to suggestions on ways to improve the API or even PRs

taylorh140 commented

2025-09-22 19:06:13 +00:00

Yeah, I don't disagree. This package makes very helpful diagrams, so I'm hugely grateful.

I feel like each structure should have its own horizontal offset for the "description" label placement. global -> force-descs-on-side, left-labels feel a bit too heavy handed.

The function overloading for values might be helpful as well, I agree binary 000010 is great but longer strings become harder to read without delimiters 00_0010 and sometimes it makes more sense to do it in hex or some other thing. So providing a typst function that can reformat this would be beneficial. Also, the ordering of numeric order might not always be desired, in the example I provide below, it would actually be nice to handle the 01 case first, and place it first since it is logically first.

The typst experience feels like a port (probably because it is), some of the auto sizing and measurement features of typst content is not used in favor of guessing text sizes and whatnot. It makes sense to do this in python land, but I think the added flexibility of this would make some of the configuration things unnecessary.

I also don't want to mix the goals here. To me this seems like you intended it for automatic diagram generation tool that should pull in data from many sources "yaml", "json" etc.

I intend to use it just for documentation so using typst syntax for things makes it more flexible.

So doing things like this are fine. Even if I have to make special adjustments for various item placements.

I might consider a making a PR, please don't take these as critical. I'm just thinking how it works over after using it a bit.

Yeah, I don't disagree. This package makes very helpful diagrams, so I'm hugely grateful. I feel like each structure should have its own horizontal offset for the "description" label placement. global -> force-descs-on-side, left-labels feel a bit too heavy handed. The function overloading for values might be helpful as well, I agree binary 000010 is great but longer strings become harder to read without delimiters 00_0010 and sometimes it makes more sense to do it in hex or some other thing. So providing a typst function that can reformat this would be beneficial. Also, the ordering of numeric order might not always be desired, in the example I provide below, it would actually be nice to handle the 01 case first, and place it first since it is logically first. The typst experience feels like a port (probably because it is), some of the auto sizing and measurement features of typst content is not used in favor of guessing text sizes and whatnot. It makes sense to do this in python land, but I think the added flexibility of this would make some of the configuration things unnecessary. I also don't want to mix the goals here. To me this seems like you intended it for automatic diagram generation tool that should pull in data from many sources "yaml", "json" etc. I intend to use it just for documentation so using typst syntax for things makes it more flexible. <img width="1175" alt="image.png" src="attachments/a04f5d00-08a5-4896-95d4-f4b5a8df3d00"> So doing things like this are fine. Even if I have to make special adjustments for various item placements. <img width="503" alt="image.png" src="attachments/84b1b6b4-006a-4152-9d06-3fe21969b341"> I might consider a making a PR, please don't take these as critical. I'm just thinking how it works over after using it a bit.

image.png

108 KiB

image.png

32 KiB

taylorh140 commented

2025-09-22 19:12:23 +00:00

I also notice it might be nice to have mergeable values (eg multiple cases that are decoded the same way merge the value into "don't care conditions" in my case final and intermediate frames are handled the same way. So, they don't need their own structure.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: HEL/rivet-typst#12