This fixes a bug introduced in commit 8365f2f and improves the previous,
suboptimal behaviour. Now, polygon fill rules should be saved and loaded
correctly; and the changes should be reverse compatible (so that files
created with an older version will be loaded correctly as well).
In some cases, export of a document containing a PDF background to PDF
caused the contents to be truncated.
The "simple" PDF exporter will now set the output page size to be equal
either to the document nominal size or, if the document has a background
PDF item, to the size of this item.
Fixed issue that appeared with previous commit, where grouped strokes'
positions were sometimes saved and loaded incorrectly.
Strokes and their transforms should now be saved correctly whether they
are grouped or not
Solves issue where items (other than strokes) that had been grouped then
moved (and/or rotated) lost their new position after saving and loading
the document.
The same font, in the same point size, can be displayed differently
depending on platform (this is a Qt limitation). This can lead to text
items being the wrong size when importing a document created on a
different computer.
As a workaround, when saving a text item to SVG, the size of 1pt in
pixels is calculated and saved. Upon loading, this value is calculated
again and, if it is different from the saved value, the text item is
scaled accordingly.
Thus, any document created from this version onward will have
correctly-scaled text boxes. If an old document (not containing a
pixel-per-point attribute for text items) is loaded, the scene is marked
as modified to make sure that all text items are then saved with the
pixels-per-point value (even if the document is not edited). This allows
old documents to be "fixed" by simply opening them once from a new
version of OpenBoard.
save text item font size in pixels, and scale it on load
fixed loading of text item pixel height
Save and load pixels-per-point rather than text pixel height
Upon loading a text item from SVG, make sure that it will be saved with a pixel-per-point value
Up until now, the fill rule of a polygon was always saved as even-odd,
despite the fact that in most if not all cases, polygons are drawn with
winding fill within OpenBoard.
Saving is now fixed, but there is no way to know upon loading whether
the polygon was correctly saved or whether; so for now, we just set the
fill rule to Winding when loading a polygon.
- The background selection palette now includes a slider to change the
size of the background grid. Default min/max values are 16 and 64px,
defined in UBSettings. Grid resizes dynamically as the slider is moved.
- Measuring tools' (ruler, triangle) markers follow grid size: 1 square
of the background grid corresponds to 1cm
- Grid size can be different for each page of a document
- Grid size is saved in the .svg
- Documents with a background grid but no specified grid size follow the
default size defined in UBSettings.
Previously, grid size was calculated based on DPI, which can vary from
one OS, computer or display to the next. This new setting allows
documents to be migrated from one machine to another with no unexpected
changes in grid size happening. It also makes it easy to correct any
problems importing old documents (whose grid size might be smaller or
larger than expected when imported on a new version of OpenBoard).
The scale of PDF items was sometimes badly calculated when opening a
document made with a previous version of OpenBoard or made on another
computer.
Specifically, this solves the following issues:
- PDF scale calculation in documents that did not specify the pageDPI
used to render the PDF (happened with documents created with some old
versions of OpenBoard)
- PDF scale calculation in multi-page documents (it was set correctly
for the first page, but not the following ones)
In some cases, the PDF background of a document could be scaled badly
when tools such as the ruler, compass etc. were present on the page.
This happened with PDFs of version <= 1.4, and when the tools were
outside of / larger than the page.
This fixes an issue where if one document was imported with a different
DPI than the current one, any document created thereafter would have
this same value (which could then cause problems if a PDF was added to
that new document).
Saving this value to UBDocumentProxy not only makes more sense, it also
fixes this issue.
Clément Fauconnier
letsfindaway
John Papale
Craig Watson