Created attachment 88929 [details]
Screenshot showing turquoise Table Design selection.
Problem description: I noticed this by selecting the turquoise Table Design in Impress (refer screenshot) and then examining the XML which contained "turquise" rather than "turquoise".
Steps to reproduce:
1. Start Impress.
2. View > Toolbars > check Table.
3. Using the Table toolbar insert a table.
4. With the table selected, double-click the turquoise Table Design in the Tasks Pane.
5. Save ODP.
6. Examine content.xml to find it contains:
Current behavior: The term "turquoise" is spelled "turquise".
Expected behavior: Spelling is "turquoise".
// ---- Turquoise --------------------------------------------------
Any aTurquise1( implMakeSolidCellStyle( pSSPool, "turquise1" , aDefaultCellStyleName, RGB_COLORDATA(71,184,184)));
Any aTurquise2( implMakeSolidCellStyle( pSSPool, "turquise2" , aDefaultCellStyleName, RGB_COLORDATA(51,163,163)));
Any aTurquise3( implMakeSolidCellStyle( pSSPool, "turquise3" , aDefaultCellStyleName, RGB_COLORDATA(25,138,138)));
implCreateTableTemplate( xTableFamily, "turquise" , aTurquise1, aTurquise3, aTurquise2 );
This seems to have been introduced in 7c6348f89d8f13623ce3f086304ddc3524cc47e1 on 2008-03-12 if I am reading the OpenGrok history correctly, so I set the version to Inherited from OOo. I hope I have that all correct.
Operating System: All
Version: Inherited From OOo
I accidentally set the component to Drawing when reporting the bug. Setting to Presentation.
Owen: I submitted a patch here:
Thank you for having noticed and declared this bug.
Excellent. The patch looks OK to my non-developer eyes. Good to be able to contribute something, however small. Thanks for the prompt fix Julien.
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":
fdo#71428: Spelling of "turquise" in Impress Table Design
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Eh. Sorry guys, but I politely disagree. The fix, as it is, causes a regression, when loading old documents in a fixed Impress, or new documents in an old Impress. In that case, the style icon in the table design pane gets duplicated (because Impress does not recognise the name anymore & therefore creates a brand-new style).
99.9% of the users do not look into the xml; most of then will be irritated by the dupe entry though.
If you still want this fixed, please catch the misspelled case at least on import (I'd personally probably just let it be. there's also the rather German 'seetang' style - I'd similarly advise translating that post-factum though).
Thorsten: I agree, there'll be problems with old doc/new version and new doc/old version and that 99% of people never look xml but:
- With the time, old LO versions won't be used anymore so case 1 will disappear
- About old docs, certainly there may be some bugtrackers filled but, once we answered why and how to fix this, the information will be spread about it. What about putting some words about it on release notes and on some FAQs to help?
Also, just wondering, if it was for something more important (eg: ODF compliance or even more important), what should we do?
Now, it's just my humble opinion so if you prefer to revert the patch, go ahead because:
- I don't know what to do to accept "turquise"
- I find it weird to put some code to deal with a fixed bug
Again, it's just my opinion, I don't pretend to know the right thing to do here :-)
Anyway, thank you for your useful review, I had thought there could be some problems (see my first comment in this gerrit) but didn't know precisely what they could be.
(In reply to comment #6)
> - With the time, old LO versions won't be used anymore so case 1 will
It's not only LO, it's the combined, installed base of OOo/LibO/AOO
since 2008, when the table feature got integrated. That's clearly >100
million copies, though hard to guess how many affected documents are
> - About old docs, certainly there may be some bugtrackers filled but, once
> we answered why and how to fix this, the information will be spread about
> it. What about putting some words about it on release notes and on some FAQs
> to help?
> Also, just wondering, if it was for something more important (eg: ODF
> compliance or even more important), what should we do?
Yes, that is my point - between the two options we have (irritate
users, albeit temporarily, and having a spelling mistake in xml), in
this case I'd prefer the not-annoy-the-users one. For odf conformance
or interop issues, that verdict probably would be different. I
currently wonder how to explain & motivate that change to our users.
Thorsten: I understand the fact it might irritate but it means that once a mistake is made and concerns the content of xml, no way to fix it (or just for rare cases) :-(
I'd prefer a fixed version even if it irritates but that's just me :-)
(Oups, forgot about OOo and AOO! (wasn't on purpose of course, really :-))
So I'll let you revert the patch and put the tracker at WONTFIX if you think it's better like this.
(In reply to comment #5)
> The fix, as it is, causes a regression, when loading old documents in a fixed
> Impress, or new documents in an old Impress. In that case, the style icon in
> the table design pane gets duplicated (because Impress does not recognise the
> name anymore & therefore creates a brand-new style).
This was my greatest concern. Bit of a learning process for me. The behaviour indicated (duplicate Table Design style icons) is certainly undesirable and to be avoided.
(In reply to comment #7)
> For odf conformance or interop issues, that verdict probably would be different.
> I currently wonder how to explain & motivate that change to our users.
I was reporting this as a user as well as someone with an interest in ODF conformance / interoperability and so have divided loyalties on this issue. I would hope we can make LO as conforming as possible, but in a way that maintains compatibility for the existing user-base. I suppose I am a bit disappointed that small changes like this are so difficult to address in an easy manner, however I can also see that having a growing list of checks on import for all these small changes would become equally undesirable over time.
Thanks for checking this Thorsten. I am happy to defer to whatever the developers feel is best. At least it is now documented.
(In reply to comment #9)
> I was reporting this as a user as well as someone with an interest in ODF
> conformance / interoperability and so have divided loyalties on this
This is neither a conformance, nor (beyond the UI glitch) an interop
question. It's just ugly xml. ;)
Nice release noting plus workaround from Julien is now at
That settles it for me, thanks to all involved!