Issue 11420 - 644m1 does not open existing forms with fields aligned to right correctly
Summary: 644m1 does not open existing forms with fields aligned to right correctly
Status: CLOSED FIXED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 644
Hardware: PC Windows 2000
: P2 Trivial (vote)
Target Milestone: OOo 1.1 Beta
Assignee: marc.neumann
QA Contact: issues@dba
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-12 13:35 UTC by phillg
Modified: 2006-05-31 14:29 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
screenshot of form correct under 1.0.2 (118.57 KB, image/jpeg)
2003-02-12 13:36 UTC, phillg
no flags Details
screenshot of form incorrectly displayed under 644m1 (118.06 KB, image/jpeg)
2003-02-12 13:37 UTC, phillg
no flags Details
Form used in screenshots (13.53 KB, text/star-office)
2003-02-12 13:55 UTC, phillg
no flags Details
Form created under OOo 1.0.0 (13.73 KB, text/star-office)
2003-02-12 16:42 UTC, phillg
no flags Details
Licensing Form under 644 as requested, zoom 150% (74.96 KB, image/jpeg)
2003-02-12 17:25 UTC, phillg
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description phillg 2003-02-12 13:35:32 UTC
Steps to reproduce:
1.  Create a form using any build earlier than 644.
2.  Align on of the fields to the right (see attachment ops under 1.0.2.jpg)

Actual result:
Opening this under 644m1 results in the field being aligned to the left (see
attachment ops under 644.jpg)

Expected result:
The field to be aligned correctly as it does under 1.0 - 1.0.2 and 643/C
Comment 1 phillg 2003-02-12 13:36:34 UTC
Created attachment 4678 [details]
screenshot of form correct under 1.0.2
Comment 2 phillg 2003-02-12 13:37:08 UTC
Created attachment 4679 [details]
screenshot of form incorrectly displayed under 644m1
Comment 3 phillg 2003-02-12 13:55:55 UTC
Created attachment 4680 [details]
Form used in screenshots
Comment 4 Frank Schönheit 2003-02-12 14:34:24 UTC
it also happens in the latest internal builds (means operations.sxw is
read incorrectly). Accepting and Starting. Bad thing this :(
Comment 5 Frank Schönheit 2003-02-12 15:25:58 UTC
(btw: discovered another bug while playing with Operatives.sxw: issue
11426)
Comment 6 Frank Schönheit 2003-02-12 16:30:01 UTC
now this is an ugly one ....

speaking strictly, the document as written with OOo 1.0.x is defect:
For right-aligned controls, it writes a
  fo:text-align="justify"
into the XML stream. Unfortunately, "justify" is not the same as
"right" - so the document is defect. Yet more unfortunately, OOo 1.0.x
itself did, while writing, produce a defect XML file, but upon
reading, it translated the wrong XML file into a _proper_ runtime
value - thus everything looked fine.

Now that we fixed the problem with the file format
(
btw: the original issue was not an IssueZilla one, but:
- open the controls toolbar
- insert a TextField or a FormattedField into a document
- open the properties
- change 'Alignment' to 'default'
- save the document
- close the document
- load the document
- open the properties for the control
=> 'Alignment' is not 'default' it is 'left'
)
, this means that OOo 1.1Beta/644 gets a improper value from the XML
file, and makes an improper runtime value out of it.
The really bad thing about it is that we don't have versioning
information in the XML file, so there is _no_change_ to determine the
version which wrote the file - thus there is no chance to determine if
the XML value is right or wrong.
Thus, we can either
1. live with the current situation
2. revert the fix which lead to this problem, accepting that the XML
documents will be broken once and forever then
3. convince the xml.openoffice.org project to include versioning
information into the fil

2. is bad because of two aspects: we will get another bug with this,
and we would accept that OOo writes broken documents
I will have a very hard time doing 3., because normally, OOo's
intention is to have _one_ file format, not a file format which
changes with every version ...
And 1. is not really satisfying, too ...
Comment 7 phillg 2003-02-12 16:42:32 UTC
Created attachment 4688 [details]
Form created under OOo 1.0.0
Comment 8 phillg 2003-02-12 16:44:17 UTC
Frank,

Please see the new attachment (Licensing Form) as the display of that
under 644 is really bad.  It doesn't seem to follow the default
alignment bug problem (or does it?).  The two fields that are
displayed correctly (Holiday Credits & Pensions) were added using 643C.

P h i l l 
Comment 9 Frank Schönheit 2003-02-12 17:01:08 UTC
situation:

aligment in OOo | written in OOo 1.0.x | written since 644
----------------+----------------------+------------------
Default         | "start"              | nothing
Left            | nothing              | "start"
Center          | "end"                | "center"
Right           | "justify"            | "end"

XML attribute | recognized as (1.0.1) | recognized as (644)
--------------+-----------------------+--------------------
"start"       | Left                  | Left
"end"         | Center                | Right
"center"      | Right                 | Center
"justify"     | Right                 | Right
nothing       | Left                  | Default

This means

* we don't really have a problem for Left- and Default-aligned
controls: at runtime, both appear as left-aligned, in both 644 and 1.0.x

* we could at least determine the "justify"-case: When we encounter an
"justify", then we could translate this into Right (instead of, like
we do currently, "Left"), so the 644 would properly read Right-aligned
controls.

* we still don't have a chance to determine the centered controls:
centered contols written in 1.0.x are recognized as right-aligned in
644, and vice versa.

* we continue to have a problem with right-aligned and centered
controls written in 644: They will be recognized in 1.0.x as exactly
the opposite.
Comment 10 Frank Schönheit 2003-02-12 17:07:51 UTC
> Please see the new attachment (Licensing Form) as the display of that
> under 644 is really bad.

Sorry, can you provide a screenshot? This document looks perfectly
okay to me in 1.0.1, 644, and the latest internal build - and it looks
identical in all three versions. The only issue is that when it is
opened in edit mode, then the vertical scroll bar seems to be
incorrect - it is positioned at the very top, but there are some
controls "leaving" the upper border of the view. Not sure what I
should think of this (perhaps it's worth another issue?), but besides
this, everything's okay here.

> The two fields that are displayed correctly (Holiday Credits &
> Pensions) were added using 643C.

This shouldn't make a different - either all fields should be broken,
or none, becase a document is always written completely from scratch -
no old content is preserved.
Comment 11 Frank Schönheit 2003-02-12 17:11:53 UTC
hmm. The proper version of the second table is

XML attribute | recognized as (1.0.1) | recognized as (644)
--------------+-----------------------+--------------------
"start"       | Left                  | Left
"end"         | Center                | Right
"center"      | Right                 | Center
"justify"     | Right                 | => Left <=
nothing       | Left                  | Default

(The marked entry was the wrong one)
Comment 12 phillg 2003-02-12 17:25:28 UTC
Created attachment 4692 [details]
Licensing Form under 644 as requested, zoom 150%
Comment 13 Frank Schönheit 2003-02-13 10:32:23 UTC
Phil, this layout problem looks really bad and certainly is more
serious that just a little scrolling problem ... I suggest you submit
an extra issue for it (it does not have to do with this one here, and
it shouldn't get lost, though I admittedly cannot reproduce it here)
Comment 14 Frank Schönheit 2003-02-13 11:53:10 UTC
Okay, I cannot completely fix this bug without changes to the XML file
format, which is near to impossible. I can fix it to the following state:

written   | Alignment | Alignment     | Alignment
with      | written   | read in 1.0.x | read in 644
----------+-----------+---------------+------------
OOo 1.0.x | Center    | + Center      | - Right
          | Right     | + Right       | + Right
----------+-----------+---------------+------------
644       | Center    | - Right       | + Center
          | Right     | - Center      | + Right

The "-" marks bug which would persist.

Phill, this would at least "fix" your document, as it contains
right-aligned (and no centered) controls.

I am not happy with this solution, as the cross-version problem will
persist (especially, documents written with 1.1 cannot be properly
read with 1.0.x), but after some discussion with our XML project guys
and QA, I think it's the only feasible way.
Comment 15 Frank Schönheit 2003-02-13 16:26:20 UTC
fixed as said above
Comment 16 Frank Schönheit 2003-02-19 09:47:45 UTC
FS->MSC: fixed in CWS APPS01 - could you please verify?
Comment 17 marc.neumann 2003-02-19 13:46:41 UTC
fixed in CWS apps01
Comment 18 marc.neumann 2003-02-19 13:47:01 UTC
verified in CWS apps01
Comment 19 marc.neumann 2003-02-23 15:44:21 UTC
ok in m4s4
Comment 20 michael.bemmer 2003-03-13 11:08:54 UTC
As mentioned on the qa dev list on March 5th I will close all resolved
<wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details. 
Comment 21 hans_werner67 2004-02-02 12:55:50 UTC
change subcomponent to 'none'