Bug 63436 - Support for ODF fields as written by KWord
Summary: Support for ODF fields as written by KWord
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp
Depends on:
Blocks: ODF-import
  Show dependency treegraph
 
Reported: 2013-04-11 16:18 UTC by Jan Holesovsky
Modified: 2017-02-14 08:58 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Holesovsky 2013-04-11 16:18:42 UTC
See the bugreport from AOO bugzilla:

https://issues.apache.org/ooo/show_bug.cgi?id=79611

We do not support this; but should be reasonably straight-forward to implement.

In essence, you need to make sure that in SvxFieldData::Create() from editeng/source/items/flditem.cxx, none of the xPropSet->getPropertyValue(...); throws.

To achieve that, you want to extend the XMLSenderFieldImportContext::PrepareField() from xmloff/source/text/txtfldi.cxx so that it fills all the appropriate properties during load, like for example:

aAny <<= text::textfield::Type::EXTENDED_TIME;
rPropSet->setPropertyValue(UNO_TC_PROP_TEXTFIELD_TYPE, aAny);

for date/time.
Comment 1 Björn Michaelsen 2013-10-04 18:48:07 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 2 Björn Michaelsen 2014-12-02 10:53:12 UTC
adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 3 George Bateman 2014-12-19 19:14:23 UTC
I cannot reproduce the bug on Ubuntu 14.04, 64-bit. Both files attached in the AOO report open fine on a freshly built copy of LO, and on my OS-supplied copy, "Version 4.2.7.2, Build ID 420m0(Build:2)".
Should this be closed?
Comment 4 Dennis Roczek 2014-12-22 15:45:37 UTC
Well, not really. The "import" works (not crash), but there are two bookmarks in the aoo bug document. 

1) called "Bezugszeichen"
and
2) called "Anrede"

Anrede is shown in the navigator, but the Bezugszeichen-Bookmark which is located before the date "7. Oktober 2005" is not visible in the navigator.
Comment 5 George Bateman 2014-12-23 15:46:45 UTC
OK, I see. Can I take this bug?
Comment 6 Dennis Roczek 2015-11-01 13:20:32 UTC
any update?
Comment 7 George Bateman 2015-11-01 13:23:05 UTC
Sorry, I realised that my C++ was rustier than I'd imagined and then forgot all about this bug. I've unassigned myself.
Comment 8 Robinson Tryon (qubit) 2015-12-14 05:03:42 UTC Comment hidden (obsolete)
Comment 9 Robinson Tryon (qubit) 2016-02-18 14:52:38 UTC Comment hidden (obsolete)
Comment 10 Dipankar Niranjan 2016-03-27 15:41:03 UTC
I can see two things from the document,
1) <draw:text-box fo:min-height="0.01pt">
     <text:p text:style-name="P2"><text:s/><text:span text:style-name="T1">•</text:span><text:s/><text:span text:style-name="T2"><text:sender-street>Steinmetzstraße 57</text:sender-street></text:span><text:span text:style-name="T2"/><text:span text:style-name="T1">•</text:span><text:s/><text:span text:style-name="T2"><text:sender-postal-code>10783</text:sender-postal-code></text:span><text:span text:style-name="T2"/><text:span text:style-name="T2"><text:sender-city>Berlin</text:sender-city></text:span></text:p>
    </draw:text-box>
part doesn't load which might be what Jan is referring too.

2) The bookmark doesn't show up in the Navigator as Dennis mentions.

Also,
<text:bookmark text:name="Bezugszeichen"/> and <text:date style:data-style-name="N1"/> seem to be throwing too as I counted 5 in SvxFieldData* SvxFieldData::Create() with three being the 'sender' ones from above.

Firstly, I need to figure out how to make part (1) from the above work.
I think its from XMLSenderFieldImportContext::PrepareField() as Jan says, but I still don't get exactly what to change even after I've been working on this for a day.

Adding the lines
aAny <<= text::textfield::Type::EXTENDED_TIME;
rPropSet->setPropertyValue(UNO_TC_PROP_TEXTFIELD_TYPE, aAny);
anywhere inside XMLSenderFieldImportContext::PrepareField() leads to an error.

By 'appropriate properties during load' am I right to assume it means everything from 
<http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/text/textfield/Type.idl>  ?

Please give some pointers on how to proceed.
Comment 11 Dipankar Niranjan 2016-03-27 20:19:25 UTC
Hi kendy,

Do I have to do something along the lines of making something like XMLExtendedTimeFieldImportContext (like XMLSenderFieldImportContext) for each of the 15 constants in type.idl (EXTENDED_TIME is one amongst the 15), make it inherit from XMLTextFieldImport context and  have a PrepareField() with the lines 

aAny <<= text::textfield::Type::EXTENDED_TIME;
rPropSet->setPropertyValue(UNO_TC_PROP_TEXTFIELD_TYPE, aAny);

that you've mentioned in comment 1?


I spoke to Dennis regarding this and he thinks likewise too..
Thanks.
Comment 12 Jan Holesovsky 2016-03-30 07:21:19 UTC
Dipankar: To get a better idea where to code, you need to open LibreOffice in a debugger, set breakpoint in editeng/source/items/flditem.cxx 's SvxFieldData::Create().  Then run the import of the document, and when the breakpoint is reached, set your debugger to stop on a throw (in gdb, it would be the 'catch throw' command), and continue the execution.

Then you'll see what exactly throws and where, and from that point, you'll hopefully have a better idea what to add.
Comment 13 Dipankar Niranjan 2016-04-01 15:52:56 UTC
From the debugger I could get the following locations about the exceptions being thrown:

When I REMOVED

<draw:frame draw:name="Rahmen4" draw:style-name="fr2" svg:x="70.8379179942pt" svg:y="289.1627056658pt" text:anchor-type="page" text:anchor-page-number="1" draw:z-index="6" svg:width="496.0638515pt" svg:height="14.0882133826pt">
    <draw:text-box fo:min-height="0.01pt">
     <text:p text:style-name="P5"><text:bookmark text:name="Bezugszeichen"/><text:tab text:tab-ref="1"/>7. Oktober 2005<text:tab text:tab-ref="2"/><text:tab text:tab-ref="3"/><text:span><text:date style:data-style-name="N1"/></text:span></text:p>
    </draw:text-box>
   </draw:frame>

from content.xml from the given test odt file, there were 6 exceptions thrown:

- throw beans::UnknownPropertyException( "Unknown property: " + rPropertyName, static_cast < cppu::OWeakObject * > ( this ) );
line 2322 from unofield.cxx (This unofield.cxx is from module sw)
- throw lang::IllegalArgumentException(); line 1942 from unotext.cxx (module editeng)

The second one looks to be thrown because the first is thrown. (Direct consequence I guess). We can get this from the stack trace.

And the above two get repeated 3 times for a total of 6 exceptions thrown.

This is probably because there are three sender fields - 'sender-city', 'sender-postal-code' and 'sender-street' in the content.xml
Comment 14 Dipankar Niranjan 2016-04-01 16:01:19 UTC
When I REMOVED
<draw:frame draw:name="Rahmen1" draw:style-name="fr1" svg:x="70.8379179942pt" svg:y="127.5592761pt" text:anchor-type="page" text:anchor-page-number="1" draw:z-index="2" svg:width="212.5421004884pt" svg:height="14.0882133826pt">
    <draw:text-box fo:min-height="0.01pt">
     <text:p text:style-name="P2"><text:s/><text:span text:style-name="T1">•</text:span><text:s/><text:span text:style-name="T2"><text:sender-street>Steinmetzstraße 57</text:sender-street></text:span><text:span text:style-name="T2"/><text:span text:style-name="T1">•</text:span><text:s/><text:span text:style-name="T2"><text:sender-postal-code>10783</text:sender-postal-code></text:span><text:span text:style-name="T2"/><text:span text:style-name="T2"><text:sender-city>Berlin</text:sender-city></text:span></text:p>
    </draw:text-box>
   </draw:frame>

from content.xml from the given test odt file, these were exceptions thrown:

- throw lang::IllegalArgumentException(); line 1942 from unotext.cxx (module editeng)
- throw beans::UnknownPropertyException( "Unknown property: " + rPropertyName, static_cast < cppu::OWeakObject * > ( this ) );
line 2322 from unofield.cxx (This unofield.cxx is from module sw)
- throw lang::IllegalArgumentException(); line 1942 from unotext.cxx (module editeng)

in the given order. This and the exceptions from the above comment are thrown when there is a breakpoint at SvxFieldData::Create() from editeng/source/items/flditem.cxx

So these exceptions are related to the bookmark within the frame.
Comment 15 Dipankar Niranjan 2016-04-01 16:02:42 UTC
(In reply to Dipankar Niranjan from comment #14)


> So these exceptions are related to the bookmark within the frame.

these meaning the ones in comment 14 and not from comment 13
Comment 13 is related to 'sender'
Comment 16 Dipankar Niranjan 2016-04-01 16:14:10 UTC
As far as I gathered after two days of looking into this, 
and looking at XMLSenderFieldImportContext::PrepareField() and other of XMLSenderFieldImportContext's methods

and <opengrok.libreoffice.org/xref/core/offapi/com/sun/star/text/textfield/ExtendedUser.idl>

I can say that we may need something along the lines of 
XML-UNO_TC_PROP_TEXTFIELD_TYPE-FieldImportContext with the 15 constants from <http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/text/textfield/Type.idl> being defined along the lines of how 'sender-city', 'sender-zip', etc. are related to XMLSenderFieldImportContext.

Please look into libreoffice/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/text/textfield directory too.

Any pointers will be of great help.
I've been on this for 2-3 days now and I really want to fix this up.