Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hboxing character styles #959

Open
mhosken opened this issue Jun 18, 2024 · 1 comment
Open

hboxing character styles #959

mhosken opened this issue Jun 18, 2024 · 1 comment
Assignees

Comments

@mhosken
Copy link
Collaborator

mhosken commented Jun 18, 2024

When a character style indicates it can take attributes, the text in that character style is first put into an hbox before being inserted into the text. This means that the text can't be line broken or take discretionary hyphens. But not every text like that needs hboxing. What is needed is a way to indicate that text in a particular style needs hboxing based on whether the attributes are actually used for typesetting (e.g. href-link or \rb). So each marker gets a flag to say if it needs to be hboxed or not. This can be analysed when the stylesheet is read and set accordingly.

If a job wants to write code to process such text it can either use \sethook{start}{mrkr}{\setbox\fredbox=\hbox\bgroup} or it can set the appropriate csname flag for the mrkr.

@davidg-sil
Copy link
Collaborator

A possibility that would keep discretionary hyphens even in text with an hbox-link would be to wrap the character style not in an hbox but a maxdimen wide vbox, and then extract the hbox from that. For some reason, hboxes created that way, (along with hboxes which only contain bitmap texfonts like cmr10) retain discretionary hyphens.
The challenge is how much would need rewriting. Things like \mark / \marks, any figures, inserts, vadjusts, and probably other things would need to end the vbox, extract the hbox into some kind of 'collecting hbox' insert themselves too, and then restart the vbox. This would need to be written so that it could nest. It's not insurmountable, but the questions are whether it's (a) worth the effort and (b) still too fragile - user code such as hooks and triggers might break it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants