KoGenStyle::rmProperty ?

[Jaroslaw Staniek]

On 29 October 2011 13:13, C. Boemann <cbo at boemann.dk> wrote:
> On Saturday 29 October 2011 13:01:59 Pierre Ducroquet wrote:
>> Quoting Uzak Matus <matus.uzak at ixonos.com>:
>> > Hi,
>> >
>> > I would like to discuss addition of a KoGenStyle::rmProperty method.
>> >
>> > There's a reason (maybe a stupid one) that I could make use of it in
>> > libmsooxml at the moment without re-designing and rewriting a lot of
>> > code.  We collect there a number of KoGenStyle variables storing
>> > predefined formatting for paragraphs that we inherit and modify by
>> > any overrides for the current paragraph.
>> >
>> > That's OK for MS Word files.  The problem is that positioning of
>> > lists in MS PowerPoint is different compared to MS Word (here also
>> > positioning of lists inside a text-box is different compared to the
>> > main text).  At the moment we construct a unique list style in case
>> > of ppt/pptx and any floating/inline shapes found in doc/docx based
>> > on both the list style and the paragraph style.  I still need to
>> > remove the inherited fo:margin-left and fo:text-indent from the
>> > KoGenStyle for the paragraph because attributes defined in the
>> > paragraph style have precedence over the list style.  Otherwise we
>> > would need a separate textlayout code for text in a text-box and
>> > that for both ODP and ODT.
>> > Of course that's the price for compatibility with MS Office.
>> >
>> > At the moment LO/OOo use a similar approach in ppt filters (we do a
>> > better job actually), but not in pptx filters.  To maintain
>> > compatibility with LO/OOo is also important, but I don't think it's
>> > doable without keeping the textlayout code simple or discussions
>> > with their developers.
>> >
>> > br,
>> >
>> > -matus
>>
>> Hi
>>
>> After a (too) quick thinking about this, I don't see why we could not
>> add a function in KoGenStyle...
>> Except for the naming issue : do not call it that way... When I saw
>> your mail title, I just did not understand what the topic was...
>> Naming it deleteProperty would be far better :)
>>
> well the reason I asked Matus to send a mail is because, we once had some
> method to manipulate styles and that wasn't kosher so we tried hard to remove
> it again.I'd like Jaroslaw's opinion on this, before we conclude if it is a
> good idea or not.

Thanks for discussing this.
So far I don't see reason not to add it except of course the naming,
which would be removeProperty() to mimick the naming in QMap and QSet.
When I look at implementation of the class: maybe we'd want to also
add removeAttribute()?

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)