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

Long abstracts break PDF title page layout #441

Closed
ghost opened this issue Nov 3, 2021 · 5 comments
Closed

Long abstracts break PDF title page layout #441

ghost opened this issue Nov 3, 2021 · 5 comments

Comments

@ghost
Copy link

ghost commented Nov 3, 2021

The TRD currently use the suse2021-ns design using <book/> elements. Unfortunately, they also include a fairly long disclaimer in the abstract. The abstract+SUSE postal address should be shown on page 2 of the book. Unfortunately, the long abstract appears to push down the SUSE postal address to page 2 somehow, despite the combined height of abstract and postal address seemingly still being much shorter than the page height.

current, broken:

bork

how it should look (faked by shortening the abstract):

kork

[cc @bwgartner ]

@tomschr
Copy link
Collaborator

tomschr commented Dec 3, 2021

I suppose, the table in the book.titlepage.verso template should be replaced with a fo:block-container. This would allow us to place the two components absolutely. One drawback might be that the disclaimer could overflow the address. Probably, this is a small risk we can take.

@ghost
Copy link
Author

ghost commented Dec 3, 2021

The table is currently 40% top row, 60% bottom row.
So the easiest option would actually be to reverse the sizing of table rows.
Doing an even more extreme 75% top row, 25% bottom row would probably also be possible, given the content on the bottom.

One thing that neither idea accounts for properly is how to deal with really really long abstracts that actually fill a PDF page.
The current option with the table isn't great, but at least there is no text overlaying other text, unlike with the absolute positioning idea.

@tomschr
Copy link
Collaborator

tomschr commented Dec 6, 2021

The table is currently 40% top row, 60% bottom row.
So the easiest option would actually be to reverse the sizing of table rows.

That would also be an option.

The current option with the table isn't great, but at least there is no text overlaying other text, unlike with the absolute positioning idea.

That's true. I suppose, it depends on how likely this will happen. Neither option is really great if the stylesheets are faced with lots of content.

I would suggest a different approach.

I'm fine to adapt the percentages of the top and bottom row as you suggested. That would be an easy fix. However, apart from this little change I don't think we should spent more time.

Such a page is not really changed much. Usually it is added at project start and never changed again. So I think, it is not so a technical problem, but more of an issue to make our writers aware of the limitations. The content has a limit and nothing what we do can change this fact.

We can all invent clever checks, but the stylesheets aren't fool-proof. It's up to the writer to come up with some reasonable content that fits into the boundaries of such a page.

If they don't follow our recommendations, it's a "garbage in - garbage out" issue and as such a "wontfix" for us.

@ghost
Copy link
Author

ghost commented Jan 19, 2022

Relevant for doc-suse-com/site#53.

@ghost
Copy link
Author

ghost commented Jan 24, 2022

I'm fine to adapt the percentages of the top and bottom row as you suggested. That would be an easy fix. However, apart from this little change I don't think we should spent more time.

I have done that in 9d9e9fc. That works for the amount of content the TRDs need for the abstract. So I am going to close this one, even as the solution is not great.

So I think, it is not so a technical problem, but more of an issue to make our writers aware of the limitations. The content has a limit and nothing what we do can change this fact.

We're using computers -- the amount of space we have is essentially endless. It's certainly more than a single page.

If they don't follow our recommendations, it's a "garbage in - garbage out" issue and as such a "wontfix" for us.

The issue with that reasoning is that long abstracts are not "garbage."
In this case, the issue is imo a situation of proper content in, unpleasantness out.

@ghost ghost closed this as completed Jan 24, 2022
This issue was closed.
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

1 participant