tdf#128153 docx/VML: apply style properties to shape text

This replaces LO 4.3 commit 8766011bccfd0f12f8dd77d2f94eb16e2e8c3471
DOCX import: set document-level font size default based on default para style

...and is needed for tdf#118947, since bogus DEFAULT_VALUEs
really hinder determining what a table style should override.

Shape text should inherit the font size from the style that is specified.
In many cases, it will not be specified, and therefore the default style
was appropriate, but in cases where a style IS specified, then of course
use that fontsize ... and every other character and paragraph property.
HOWEVER, I only added the properties used in vml import for now,
and I skipped asian/complex fontnames since VML only handles CharHeight,
and not CharHeightAsian/Complex.
-note: this does not affect direct formatting - it just sets
default value at the shape level, not at the paragraph level.

So far I have only looked at DOCX:VML - which satisfies the
unit tests. There are other codepaths that lead to PushShapeContext
though, and this should be easy to expand to other import
situations. I've tried lots of asserts to find unit tests
that should be modified, and so far they all seemed to point
to VML - although round-tripping doesn't use VML and still
requires at minimum the CharHeight property to be overridden,
so limiting non-VML to that to maintain backward compatibility,
and reduce regression footprint.

Since we have to emulate here (since paragraph styles are not
supported on Draw text), a perfect solution cannot possibly be
found - specifically in cases where multiple paragraphs exist
in one shape with different styles applied, or where some
pararaphs apply a paragraph property and others do not.

Compromise 1: For ambiguous paragraph styles, fallback to the
default paragraph style. Rationale: Normally, most styles
inherit from default and only change a couple of properties.
So MOST of the properties will match the normal style.
The chances that the default style will be correct are
more likely than that some other random default would be.
-note: no existing unit tests were ambiguous

Compromise 2: Ideally, each paragraph could report whether
it had DIRECT formatting, and the paragraphs could be
walked through instead of the shapes. But I don't think
that is reasonably possible in this SyncProperties situation.

At first I had a grabbag framework setup that monitored
when a paragraph property was set, and then skipped applying
that property. But I later noticed that the PropertyState
for paragraph properties actually did seem to reflect
that - which is a better solution if it works properly.

Regression potential:
-for VML: should be limited to non-charheight properties
where the default style sets some weird default, and
an ambiguous style sets it back to the program default.
Prior to this patch, the default style value wouldn't apply.
On the flip side (and more likely scenario), non-ambiguous
cases will use the correct value and look more like MSWord,
as seen in many existing unit tests that now use corrected fonts.
-for non-VML: should be none since I limit it to only
CharHeight which was previously emulated by changing the
program default.

Change-Id: I8f1fb7ed01f990dbf998ebe04064c2645a68e1aa
Reviewed-on: https://gerrit.libreoffice.org/81365
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

0 files changed, 0 insertions, 0 deletions