Fix PDF text attributes in logical children #7092
Conversation
|
I want to come up with some more descriptive names for the logical parenting behaviors. |
saecki
force-pushed
the
tag-tree-text-attrs
branch
3 times, most recently
from
b660ae6 to
a289bfc
Compare
|
Well, I couldn't come up with better names 🫠, but I updated the documentation a bit. |
saecki
force-pushed
the
tag-tree-text-attrs
branch
from
a289bfc to
4bf1ca9
Compare
|
I've also refactored the text attribute computation a bit. |
crates/typst-pdf/src/tags/groups.rs
Outdated
| /// See [`FrameParent`]. | ||
| #[derive(Debug, Copy, Clone, Eq, PartialEq)] | ||
| pub enum LogicalChildKind { | ||
| Inherit, |
There was a problem hiding this comment.
It seems odd to me to have two parallel enums (this and FrameParent). Wouldn't it make more sense to have FrameParent be a tuple or struct consisting of a Location and this enum?
There was a problem hiding this comment.
The naming being difficult perhaps also indicates that this is really only a bool: inherit. Or alternatively separate to indicate that it does not inherit the styles. Not sure which is the clearer default.
There was a problem hiding this comment.
I've decided to go with an Inherit enum that has a yes and a no variant. I wanted to go with the boolean, but that way the documenation was attached to the field in FrameParent, and it seems to be more relevant in the PDF export.
saecki
force-pushed
the
tag-tree-text-attrs
branch
from
4bf1ca9 to
f9a3b5e
Compare
2 participants
Related comment
This fixes a bug with text attributes inside of logical children, and also resolves some inconsistencies with how footnote entries were previously handled in tagged PDF. Now they are in line with how realization/layouting handles them.