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

Eat last space of non text element #4087

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

LuxxxLucy
Copy link
Contributor

@LuxxxLucy LuxxxLucy commented May 7, 2024

updated

This PR adds a bool to Segment::Spacing and Item::Absolute so that when layouting a line, the weak space in the beginning or the end of the line is removed. Note that spaces introduced by math (MathParItem) are made to be weak space. Otherwise space are specified by the weak attribute such as #h(..., weak: true).

Test cases are updated with the following names

  1. trim-weak-space-line-beginning
  2. trim-weak-space-line-end
  3. issue-4087: which includes the cases raised by @laurmaedje in the comments.

Old

Math Equations might introduce a whitespace as a item to be layouted. For normal text, any white space at the end of line is trimmed; but for white spaces introduces by math equations this procedure of trimming space is not applied.

Essentially, whether a space is eaten/trimmed is a decision made during linebreak algorithm, so like in text elements we can only decide whether to trim the trailing whitespace during actual line construction when we know that a certain range of items is going to be layouted in a line; we need to make the decisions for math-equation-introduced white space when we are doing actual line construction.

Context: this bug is brought up in #3953 which planned to add decoration for math equations #2200, during the process this bug is brought up and it seems if this bug is fixed the solution of #3953 would not be working. So this PR proposes to solve the whitespace bug first, and we can figure new ways for #2200

I am hoping to fix this bug and then continue to on revising #3953 to solve #2200

@laurmaedje
Copy link
Member

Ignoring any kind of spacing at the end of the line is a bit problematic, as it might be an intentional h(..). Consider e.g.:

#set align(right)
Hello #h(2cm)

What could be a good alternative is only doing this for weak spacing. I've on multiple occassions thought that it's somewhat odd and maybe a bug that h(.., weak: true) is not omitted if it happens to fall next to a linebreak.

@LuxxxLucy
Copy link
Contributor Author

LuxxxLucy commented May 7, 2024

Ignoring any kind of spacing at the end of the line is a bit problematic, as it might be an intentional h(..). Consider e.g.:

#set align(right)
Hello #h(2cm)

What could be a good alternative is only doing this for weak spacing. I've on multiple occassions thought that it's somewhat odd and maybe a bug that h(.., weak: true) is not omitted if it happens to fall next to a linebreak.

Yeah after think about it is is a littlle bit problematic. I will take a look so that we only consume weak space. BTW how do you see the updated test case for bidi-reset-whitespace? (I checked the commit history and seems to be early commits done by you @laurmaedje )

@laurmaedje
Copy link
Member

Looks like the text space before the #h(70pt) is trimmed, leading to only the Arabic font being used, which changes the line height. If the spacing was weak, that would probably be correct, otherwise it isn't.

@LuxxxLucy
Copy link
Contributor Author

Okay I just read the code and some relevant PRs about weak spacing. It seems to me that mainly the weak space is all handled inside the Equation and would not really be handled properly when the space item goes into linebreak. So I think we will modify some data structure to pass the weak attribute so that the later linebreak procedure can know whether a space is weak or not.

For the example you provide, I think I understand the expected behaviour for this is the non-weak space would be preserved

#set align(right)
Hello #h(2cm)

But I am still a little unsure of what you mean by the following

What could be a good alternative is only doing this for weak spacing. I've on multiple occassions thought that it's somewhat odd and maybe a bug that h(.., weak: true) is not omitted if it happens to fall next to a linebreak.

I am not sure about what the expected behaviour would be (Can you elaborate on this a little? And then I can put into new test cases)

@laurmaedje
Copy link
Member

For the example you provide, I think I understand the expected behaviour for this is the non-weak space would be preserved

Exactly.

But I am still a little unsure of what you mean by the following

Just what you said above: Weak spacing is removed, non-weak spacing is preserved. If a line happens to end with or start with a weak spacing, we trim it.

Basically, my idea was to add a bool to Item::Absolute which indicates whether it is weak. This would be true for MathParItems, but also for h(.., weak: true). And then we successively trim the weak spacings and other trimmable whitespace at the end of a line.

This code snippet illustrates the problem (with default A4 page, not test runner style):

#lorem(15) #h(5cm, weak: true) #lorem(5)

There are actually multiple issues here: First that the h forces the last word onto the next line (because there is no linebreak opportunity between the first text space and then h) and then that it doesn't disappear. Both would be fixed if it were trimmed. hough the first issue remains with non-weak h. But that's sort of unrelated I guess.

@LuxxxLucy
Copy link
Contributor Author

PR updated. Now will propgate the weak attribute to segment::spacing and item:absoulte, which will be used in line layouting.. Now added three test cases trim-weak-space-line-beginning, trim-weak-space-line-end, issue-4087

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

Successfully merging this pull request may close these issues.

None yet

2 participants