Open AndrewMD888 opened 3 years ago
Hmm, that's an interesting one. Detecting being at "the bottom of a page" would be difficult because the definition of what a "page" is, isn't defined by MicroPad-- you could print to A4 or A3 for example. It'll definitel be worth looking into with https://github.com/MicroPad/MicroPad-Core/issues/176 though.
In Chrome there is a PDF preview on https://web.getmicropad.com by the looks of it:
Potentially something like https://github.com/aaronholla/electron-print-dialog could be used or something more custom to bring a more useful dialog to the electron app.
Could MicroPad use the total number of lines within for each document format size to conditionally choose where to move the asciimath/LaTeX rendered text? Or does that change for different files/pages, and is it not a standard?
I spoke about the problem with MicroPad printing the asciimath rendered content on pages in PDF files before on GitHub, and it still is hard to find out or know where the bottom of each page will be when writing mathematical documents, as if the rendered text is at the bottom of the page then one line can easily become broken and printed partially on two pages. If the desktop program had the option to preview the PDF file, or how it would be printed before creating the file, it would save a lot of time. Right now I get the file, check it, and then add HTML line breaks to rectify this problem. It is not efficient and sometimes takes 3 or more file creations and checks to sort out the formatting. Otherwise, a fix for the core issue at hand would be better so asciimath/LaTeX rendered lines could autodetect when they are at the bottom of a page, and then put themselves on the start of the next page or some other solution for the format preservation.