What were you doing: pdf export / printing document
What feature did you use: cmd + p / export button
What happened: Tables get cut off on the right side of the pdf page
What did you expect to happen: That the full table is visible when exporting my document
Every time I try to print a document that contains a table, I have to export it to .docx format first and then print from there to ensure the full table is displayed.
It would also be amazing if the PDF export/print could match the style settings chosen within the app, though I understand this might be more of a feature request than a bug.
Thank you so much for taking the time to look into this issue! I really appreciate your help and support.
~ Clemens
I’m unsure about how to call this. The problem is, to be print-ready, the PDF exporter adopts the A4 page format with margins and if the table doesn’t fit we don’t know what to do.
One solution is to split the table and report the columns that don’t fit below the original table. This pretty much makes the table unreadable.
We can do the table vertically on a dedicated page but it might not fit as before and breaks the document flow. We can change the A4 format and widen the document according to the table size but I’m pretty sure this is not what most people want (maybe the JPG exporter is better for this purpose).
I understand that in the above scenario there is no good option to display the table, there has to be some sort of compromise. (Although the way it is now is probably the least optimal one - I would probably just make the table so small that it fits completely on the page…).
Anyways, my problem here is a different one. As you can see in the screenshot below the table is fully rendered (without having to scroll) in the bear app. In the pdf there are just a few pixels missing.
Interestingly, the direct comparison shows that the width of the table is different in the bear app and in the pdf. For example the word “amet” is in the first line inside the pdf, but in the second line in bear.
This looks like the same issue to me. The PDF the exporter produces might have a different column width compared to the editor (not to mention possibly font sizes and typefaces) and here the table is cut for the reasons mentioned above.
Then why not have the same column width, font size and typeface in the exporter? Or just adjust the table width so that it fits in the exporter (making the table a bit narrower but longer as well)? Or cut off the table at the last column, which can be rendered fully?
Right now it just looks very bad, because the exporter cuts off the table randomly (even in the middle of a letter…).
There has to be a way to display a full table in the exporter, if it is fully displayed in the editor.
Our idea of the PDF exporter is something that can be used for printing so, as I mentioned before, we are bound to use the A4 column width. We also don’t think it’s a good idea to export the editor’s typographic preferences for the same reason.
My understanding is you don’t want to use the PDF for printing but rather for sharing and I’ll take it into account, but I’d like to see more opinions on this subject.
Perhaps I am over-simplifying here, but from my perspective, here is what would solve this…
Have the margin’s in the editor lock to A4 (or an option to do so), so that what we see is what will export in either PDF or JPG. I’m assuming, this will be influenced by what CommonMark specification allow?
Anyway, I care because I often want to share via PDF, but sometimes formatting does not look like it does on screen. So, I have to export to another app and format and then export to PDF before I can share with others.
I can see some sense in providing an A4 indicator for the width size in the preference but also a lot of problems and I’m very unsure about the WYSIWYG approach (especially on mobile).
I think for you too the point is the PDF is not for printing but for sharing. If this is the case for more maybe we can provide a custom-width rendering.
(First of all, thanks for the great work you guys have done with Bear! Love the app)
I’m not convinced that the issue is caused by the content input by the user exceeding the page limit. I suspect it’s the default column width.
I noticed some strange behaviours while testing. Basically, any table that has more than 4 columns would lose pixels when exporting to pdf or printing, even if the table is as simple (or narrow) as
The last one is to show how the underlying markdown code looks like.
If we compare the two tables in test document 3, it is clear that there could have been a way to print 5 columns without exceeding the page width, but both tables are cropped by a few pixels on the right.
By accident, I found out that the bug is specific to the macOS version of Bear. On iPadOS (or iOS), the following tables are correctly exported to PDF without cutoff. It’s the same note synchronised across the devices.
).
