Closed ghost closed 2 years ago
tomschr
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago Relevant for https://github.com/doc-suse-com/site/issues/53.
ghost
commented
2 years ago 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.
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:
how it should look (faked by shortening the abstract):
[cc @bwgartner ]