We have a tool in our document editor that allows users to display a list of images that can be very long and we also allow them to justify it right/left/center. This list often will extend to multiple pages. We use flex to wrap these based on the justification the user selects. When we go to convert these to PDFs if the list of images is too long, it breaks to the next page. This works pretty well BUT because we used flex, it doesn't maintain the correct height of the container (this is controlled by the flex attribute) so any text on the next page gets overlapped by the images that broke to that page. We have tired using a mix of inline flex and more basic CSS but nothing allows the clean page breaking and dynamic sizing like flex does. Is there any solution that would solve this that works with prince? Or any plans of adding better handling for breaking across containers with flex applied?

For some added context, we know the width of the images but do not know the bounding box of the parent container so a more manual solution of calculating the needed space and breaking manually is not an option. The solution needs to be dynamic.

To answer your last question first, yes, we plan to keep improving fragmentation with the various types of flex containers. The exact details of flex fragmentation are not specified in CSS, however, so this will be an ongoing task. User feedback really helps, particularly when it comes to prioritizing the work.

We can often help with workarounds, but you'll need to tell us more about the specific circumstances. Can you provide a small example of what you are trying to do?

We have documents that are templates for how to display data. Let's say each object has a name, a list of images, and a string value as a description. The document template renders the name at the top, then below that the list of images as a grid so depending on the size of the images we fit as many as we can in a row, then wrap to the next line and so on (typical example is a grid of 3 images across for x rows). This container of images needs to be dynamically resizing/wrapping based on the dimensions of the images (some objects have large images, some have smaller so one object might layout 3 across while another might only do 2 across and wrap the subsequent to the next line). Below the image container, we render the description. When the object has enough images that would require breaking across a page, the remaining images break correctly and still wrap but the hight of the container is then messed up and the text below clashes with the wrapped images. See attached pdf (where it overflows) and pre converted html

1. Related 1 _ Doc view, simple overlap (Related 1 2) - Nov 10, 2025-45WaKml29ZJz4MQYXF69.pdf.html‎ 4.8 MB
2. Related 1 → Doc view, simple overlap (Related 1 2) - Nov 10, 2025-45WaKml29ZJz4MQYXF69.pdf‎ 431.3 kB

The underlying problem is that our flex column containers don't consistently adjust their height to account for fragmentation, and in the case of large unbreakable elements such as images the difference can be very significant. That's something we are working on.

Various workarounds are possible right now, but the simplest seems to be to not use flex display for the .block-container elements. The images are being correctly handled by the flex row container that they are in; it's the parent .block-container that is causing the problem.

Is there something particular about flex column display that you need for the .block-container, such as prevention of margin collapsing?

We tried that but then ran into an issue where there are other element's as children of the block container element's (siblings of the image container) that rely on flex, specifically we allow users to set that top level block direction as either row or column which is not supported if flex is removed.

I've added a reference to this forum topic to the relevant entry in the roadmap.

Do you have any other ideas on how we could currently support this without using flex?

We can try help with workarounds to achieve a specific layout outcome. For what you describe you might consider modifying the CSS before it gets to Prince.

For the more general solution where you can "rely on flex" I've put this down as "+1 for the no-flex column use case". If you have further questions or comments about prioritizing this work, you can contact mikeday@yeslogic.com directly.