diff options
| author | Caolán McNamara <caolanm@redhat.com> | 2016-11-18 10:41:27 +0000 |
|---|---|---|
| committer | Caolán McNamara <caolanm@redhat.com> | 2016-11-18 10:53:10 +0000 |
| commit | c80a0fcdd9a4389616e92cfeafa9d932a784ee71 (patch) | |
| tree | 7152e67b54bd5dd728c938c69d3d1ee70596c453 /sw/source/filter/ww8/ww8par3.cxx | |
| parent | 0a840edcc19ad1b8bb1525717d91ce8ade0c0092 (diff) | |
Resolves: tdf#91916 different word 6/7 vers have ambiguous sprms
See tdf#91916, #i8726, #i42685# there is an ambiguity around certain properties
as to what they mean, which appears to be a problem with different versions of
the file format where properties conflict, i.e.
ooo40606-2.doc, magic is a699
: 0x6f 0x4 0x0 0x71 0x4 0x0
ooo40635-1.doc, magic is a699
: 0x6f 0x4 0x0 0x71 0x4 0x0
ooo31093/SIMPCHIN.doc, magic is a699
: 0x6f 0x2 0x0 0x70 0x0 0x0 0x71 0x2 0x0
: 0x6f 0x5 0x0 0x70 0x5 0x0
ooo31093/TRADCHIN.doc, magic is a699
: 0x6f 0x1 0x0 0x70 0x0 0x0 0x71 0x1 0x0
ooo31093/JAPANESE.doc, magic is a697
: 0x6f 0x2 0x0 0x70 0x0 0x0 0x71 0x2 0x0
ooo31093/KOREAN.doc, magic is a698
: 0x6f 0x2 0x0 0x70 0x0 0x0 0x71 0x2 0x0
ooo31093-1.doc, magic is a698
: 0x6f 0x5 0x0 0x70 0x5 0x0
ooo31093-1.doc, magic is a698
: 0x6f 0x5 0x0 0x70 0x5 0x0
meanwhile...
ooo27954-1.doc, magic is a5dc
: 0x6f 0x1 0x81 0x71 0x2 0x4 0x0 0x74 0x2 0x20 0x0
ooo33251-1.doc, magic is a5dc
: 0x6f 0x1 0x81 0x71 0x2 0x3 0x0 0x74 0x2 0x1c 0x0
---
So we have the same sprm values, but different payloads, where
the a5dc versions appear to use a len argument, followed by len
bytes, while the a698<->a699 versions use a 2byte argument
commit c2213db9ed70c1fd546482d22e36e4029c10aa45
INTEGRATION: CWS tl28 (1.169.24); FILE MERGED
2006/10/25 13:40:41 tl 1.169.24.2: RESYNC: (1.169-1.170); FILE MERGED
2006/09/20 11:55:50 hbrinkm 1.169.24.1: #i42685# applied patch
changed 0x6f and 0x70 from Read_BoldBiDiUsw to Read_FontCode for all versions.
In the Word for Window 2 spec we have...
78 //sprmCMajority
80 //sprmCFBoldBi
81 //sprmCFItalicBi
82 //sprmCFtcBi
83 //sprmClidBi
84 //sprmCIcoBi
85 //sprmCHpsBi
as see in GetWW2SprmDispatcher, different numbers, but the sequence starts with
the same sprmCMajority as appears before 0x6f in word 6/95
I think the easiest explanation is that the CJK Word for Window 95, or whatever
the product was went rogue, and did their own things with at least first three
slots after sprmCMajority to do a different thing. I have no reason to think Tono
was wrong with what they do in the a698<->a699 versions versions, but with magic
a5dc they probably did mean sprmCFBoldBi, sprmCFItalicBi cause they have that 0x81
pattern which has significance for those types of properties.
Change-Id: I44aabf7443391bae21ed5adb074780a1c929a80d
Diffstat (limited to 'sw/source/filter/ww8/ww8par3.cxx')
| -rw-r--r-- | sw/source/filter/ww8/ww8par3.cxx | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sw/source/filter/ww8/ww8par3.cxx b/sw/source/filter/ww8/ww8par3.cxx index 3f41f87415ea..5c34fe8c74aa 100644 --- a/sw/source/filter/ww8/ww8par3.cxx +++ b/sw/source/filter/ww8/ww8par3.cxx @@ -1136,7 +1136,7 @@ SwNumRule* WW8ListManager::GetNumRule(size_t i) // oeffentliche Methoden WW8ListManager::WW8ListManager(SvStream& rSt_, SwWW8ImplReader& rReader_) - : maSprmParser(rReader_.GetFib().GetFIBVersion()), rReader(rReader_) + : maSprmParser(rReader_.GetFib()), rReader(rReader_) , rDoc(rReader.GetDoc()) , rFib(rReader.GetFib()), rSt(rSt_) , nUniqueList(1) |