https://bugs.freedesktop.org/show_bug.cgi?id=75376

V Stuart Foote <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal
             Blocks|                            |65675

--- Comment #16 from V Stuart Foote <[email protected]> ---
Not a blocker, but it is a regression, lowering priority but adding to 4.2 MAB
for review.

Affecting Windows builds only where it does appear in Windows but not Linux
release of Version: 4.2.2.1
Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f

Nor does it show in
Version: 4.2.3.0.0+
Build ID: 90aad4ad6aa814710ce7553cb196392da949e9a8
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-03-01_05:36:21

nor any builds of master (including Christian's TB47).

As noted, the <Ctrl>+F8 toggle of field shading, turns the errant characters on
and off. The errant text can not be selected/copied, suggesting it is an issue
with the rendering used to apply the field shading for these dynamic fields. I
unpacked the .odt and searched but could not figure out the XML for assigning
shading. I do see the correct text for each field entry in the content.xml.

Looking at the resulting document, the two date fields --shown as Date(Fixed)
when toggled with <Ctrl>+F9-- are correctly formed/rendered, as is the text in
the 'Date needed by' and 'GL Account#' fields. Problem appears in the
formatting of the fields holding the other inserted text--'Check amount',
Needed for', 'Check to', 'Address', and 'Requester'. Each of these shows a
field shading width of 1 character and also the same fixed errant text: "ÀxéS"

@Charles, can you provide additional detail of how you built the form. And how
the fields are populated. Can you attach the form template?

I'm unable to capture the actual byte code for the displayed text, but suspect
it is a somehow corrupted paint command for rendering the field shading. It is
interesting in that the resulting text object is persistent enough to be
treated as misspelled text, although it can not be further selected or acted
upon (with spell checker F7 frame).

To me what is odd, is that this mishandling of field shade rendering manifests
in the TDF release builds for Windows only, but is not apparent in any of the
TinderBox builds. So is this some sort of MSVC++ Windows build GDI issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to