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
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)
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.
- Removed inheritance of UBGraphicsProxyWidget; cleaned up related code
- Added two children classes: UBGraphicsVideoItem and
UBGraphicsAudioItem. UBGraphicsMediaItem is now an abstract class.
- Better encapsulation; the Scene and other external classes no longer
access the mediaObject directly
There is now less distinction between audio and video items to outside
code: apart from the UBSvgSubsetAdaptor, there is no need to know
whether a media item holds a video or audio file. Creation is handled
through the static function `UBGraphicsMediaItem::createMediaItem(URL,
parent)`
- Modified UBvgSubsetAdaptor to correctly save and load strokes, so the
transform matrices that were saved are now loaded correctly.
- Added handling of mousePress / Move / Release events to
UBGraphicsStrokesGroup, so that the transform matrix is calculated and
stored after moving a pen stroke directly (by clicking on it, and not on
its frame). Note: this duplicates quite a bit of code that is in
UBGraphicsDelegateFrame. It may be best to go back and modify both
classes so that the same functions can be called when moving a stroke.
Presumably due to the change in how pen strokes were saved to file (commit
8ed2e24), pen strokes with pressure levels were badly saved. They were
converted to lines instead of polygons, meaning that every time a page
was saved or duplicated, the lines would look worse and worse -- and
artefacts would appear.
This should now be fixed.
Page DPI is now saved as the DPI that was read when opening the file.
While not a perfectly fool-proof fix, it will at least allow files to be
migrated between OB 1.02 and 1.10.
- Added an overload for setMatrix in UBGraphicsMediaItem, to propagate
matrix changes to the child videoItem
- Upon loading a video, the child videoItem is now added correctly, and
set to the right position
The lines removed in this commit led to (presumably) unintended
behavior: when saving a document, pen strokes were saved not as a group,
but just as their constituent polygons.
This meant that the following block of code, that handles saving pen
strokes correctly, was never executed.
This doesn't fix the z-Value issue (#12), but it seems to be a step in the right
direction.