https://bugs.documentfoundation.org/show_bug.cgi?id=99569
Bug ID: 99569
Summary: Rendered EMF+ has low DPI when zoomed and printed
Product: LibreOffice
Version: 5.2.0.0.alpha1
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: filters and storage
Assignee: [email protected]
Reporter: [email protected]
Created attachment 124721
--> https://bugs.documentfoundation.org/attachment.cgi?id=124721&action=edit
Screen showing the low dpi for rendered image
I have been investigating why certain EMF files containing text are rendered at
a low resolution in LibreOffice Draw when printing or magnified(zoom) to 400%
For example: Attached libre.png (using attached Template.emf )
Note, this example file does display correctly by setting the
"EMF_PLUS_DISABLE" environment variable.
This is because the "Template.emf" "EMF" records contains the text drawing, and
the "EMF+" records do not display anything important.
Of course, ideally we should not need to set this environment variable
If "EMF+" is detected in EnhWMFReader::ReadEnhWMF(), then a different code path
is used and the "EMF" is rendered to a bitmap at the incorrect DPI, then drawn
to the screen.
So when "EMF_PLUS_DISABLE" is set:
At
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/filter/wmf/enhwmf.cxx#n621
EnhWMFReader::ReadEnhWMF() Renders the EMF directly to WinMtfOutput (pOut), and
ignores EMF+
When "EMF_PLUS_DISABLE" is not set:
At
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/filter/wmf/enhwmf.cxx#n621
EnhWMFReader::ReadEnhWMF() Detects EMF+ using the signature in EMR_GDICOMMENT
(the value 0x2B464D45, which is the ASCII string "+FME)
If detected, this is where it gets complex.
EnhWMFReader::ReadEnhWMF() only processes EMR_GDICOMMENT's (i.e. No longer does
any drawing)
EnhWMFReader::ReadEMFPlusComment()
1. Creates a header MetaCommentAction( "EMF_PLUS_HEADER_INFO" )
2. Creates the body MetaCommentAction( "EMF_PLUS" )
The drawing layer eventually calls GDIMetaFile::Play and creates a bitmap to
render to in GDIMetaFile::ImplPlayWithRenderer()
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/gdi/gdimtf.cxx#n383
This leads to ImplRenderer::processEMFPlus() (
https://cgit.freedesktop.org/libreoffice/core/tree/cppcanvas/source/mtfrenderer/emfplus.cxx#n1811
) Which processes the EMF+ commands Notice, this code is in cppcanvas (not vcl)
Still within GDIMetaFile::Play, EnhWMFReader::ReadEnhWMF() is called. The EMF
still may contain nested EMF+ data (treated as above). When no EMF+ data
exists, the standard EMF is drawn.
I am confused why we do it this way. There must have been a reason place the
EMF+ code in cppcanvas (i.e. not alongside the EMF). I cannot understand why
each layer is drawn to a different bitmap (also why it's the incorrect DPI)
There is a lot of good code there, and probably fragile. imho, it's risky
moving EMF+ out of cppcanvas, and not something that I would want to attempt.
The easy fix would be to fix the DPI setting, however I cannot find where the
error is.
Thanks
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
