feature to help book designers debug their line grid

[perado42]

Dear WeasyPrint Team!

First of all: Thanks a lot to the maintainers here for creating WeasyPrint and making it open source. I am in the middle of doing an expansive book-publishing project with WeasyPrint and have found it absolutely great. I'm sure this software has a bright future.

This PR is a piece of functionality that I've added that helps me in debugging design issues for the book. There seems to be a pretty hard rule within the design profession that lines of a book on two opposing pages should always line up to the same raster. This is not always easy to do in HTML, since HTML will reflow stuff and if there is even a single box that is not the height you are expecting it to be, then it will move everything below it and push all the lines to go out of alignment.

So I've created this function where, by adding the parameter --grid-debug somefile.csv, weasyprint will create a file somefile.csv that the designer can expect to check if lines have the expected heights and their y_positions line up with each other.

I'm hoping other people might find this useful, hence the PR.

Thanks again, and keep up the good work!

cheers,

Richard

[liZe]

First of all: Thanks a lot to the maintainers here for creating WeasyPrint and making it open source. I am in the middle of doing an expansive book-publishing project with WeasyPrint and have found it absolutely great. I'm sure this software has a bright future.

❤️

This PR is a piece of functionality that I've added that helps me in debugging design issues for the book. There seems to be a pretty hard rule within the design profession that lines of a book on two opposing pages should always line up to the same raster. This is not always easy to do in HTML, since HTML will reflow stuff and if there is even a single box that is not the height you are expecting it to be, then it will move everything below it and push all the lines to go out of alignment.

That's really useful, thanks!

For reasons explained in another comment, I think that it would be better to add this code in the documentation, not in WeasyPrint.

Do you want me to do this for you?

[perado42]

Are you sure you're not getting confused between my two PRs now? I submitted two PRs almost simultaneously:
#932: facility to override font metrics
#930: feature to help book designers debug their line grid (this)

You're pointing to a comment explaining that it's a bad idea to start coloring outside the lines as far as the HTML/CSS specs are concerned. Point well taken. But it would seem to apply primarily to the other PR (#932).

This PR is about creating a logfile that designers can use for debugging issues with line grids. Book designers are likely to want to pay close attention to those grids, as there seems to be a hard and fast rule in the profession that lines on opposing pages of books are supposed to always line up with each other which is not always easy to achieve with HTML. So a logfile like this can be of great help here.

I think that's a feature that makes sense, even while rejecting the other PR.

[liZe]

Are you sure you're not getting confused between my two PRs now?

No, I'm not. But my answer was not as clear as it was in my head, sorry 😄.

Debugging the line grid is useful when you want to understand what's going on with text. We could have the same kind of features to track boxes positions and sizes, to show flex metrics, to explain table layout, and so on. That's what browsers do. The problem with this kind of features is that you can always add more, and even if they're small and clean (and your PR is), they add complexity and have to be maintained in the future. Moreover, information needed when debugging highly depends on what you're exactly trying to debug, and you'll always need an extra field that's not included yet.

That's why I'd prefer to have this in the documentation. I think that it can be added only using monkey patching, and the code snippet will be adapted for each use case if needed.