Hi Stuart, all So I went over again all of these character backgrounds.
First of all it does not really matter whether ODF supports this feature or not, because we can extend it anytime when we have a good reason to do that. The question here: it's worth to have a highlighting feature on the top of our existing character background or not. Second thing, I compared these three kind of character backgrounds and found that LO's character background is closer to MS shading attribute then to MS highlighting, because: - LO's background color is a general attribute for different objects like text range, paragraph, frame, page, cell and so on, and character background is a specialization of it (like shading). - LO's background color and MS shading both has more color to choose from, while MS highlighting allows only 16 colors. - LO's background color and MS shading has a meaning like "fill the selected object's background with a color", while highlight has the meaning like "highlight a text range with a highlighter pen". So IMHO LO background color should be exported as shading to MS file formats and not as highlighting. Only similarity between LO's background color and MS highlighting is the "Highlighting" toolbar button and this is the problem here. Why LO uses an other name for character background on the toolbar and why not use exactly the same name (e.g. as in the menu)? This causes the misconceptions we have here. So my new plan is: - Remove "Highlighting" toolbar button - Replace it with the existing "Background color" toolbar button (set it as default) - Extend the functionality of this "Background color" button to be able to set character background too (By now it is used for setting paragraph, frame and cell background) With that the toolbar icon of LO's character background will be similar to that which is used in Word for setting MS shading attribute (a paintbucket). This also means we don't need to support highlighting in LO to solve this interoperability problem. With respect to RES_CHRATR_HIGHLIGHT attribute it's still useful to store MS highlighting on a separate attribute so an MS file won't loose shading/highlighting information during a round trip. We can solve that on a transparent way, so the users won't know that we have two kind of character backgrounds behind the scenes. UX guys, your opinions also would be appreciated here. Best Regards, Tamás 2015-02-10 1:28 GMT+01:00 V Stuart Foote <vstuart.fo...@utsa.edu>: > Zolnai, * > > Did not realize there were actually two OOXML/MSO attributes that had to be > manipulated to handle highlighting in MS Office formats. And that we'd been > fudging it with just one--your patch with just one > attribute--RES_CHRATR_HIGHLIGHT manipulated as background fill in LO. > > This recently came up in a new twist, over how we've been handled it--since > your work 2013-09--needing to turn highlighting on or off by selection and > removing direct formatting background fill. (tdf#88990). That has been a > bit cumbersome but works to clear the direct formatting in an imported > docx/doc document that either shading or highlighting receives as an ODF > document. > > Should we care about this from an ODF 1.2 standards perspective? Since we > apply direct formatting to give background fill "highlighting" to ODF > documents--is there any way in ODF to differentiate formatting that is > "highlighting" vs. what is "background fill"? I don't know... anyone? > > If there is a specification for it in ODF , then certainly creating an .uno > action and GUI button to apply a "highlighting" style, or direct formatting > of text, would be correct. But if we are just pursuing this for > "interoperability" seems like we are chasing our tails over it. > > If there is not, then why should we care that OOXML/MSO and ODF diverge on > this handling? Seems like in that case, we should continue to make do with > only background fill mapping of DOCX/MSO highlighting on import. And on > export we don't differentiate--it all remains background fill in the > DOCX/MSO formats. > > Key is what ODF 1.2 supports, or maybe what is proposed in 1.3 that might > also be implemented. > > > =-refs-= > https://bugs.documentfoundation.org/show_bug.cgi?id=64490#c14 > http://cgit.freedesktop.org/libreoffice/core/commit/?id=8b949134441056a1455d67ddfdd7e0bc5f2ee682 > http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5e60724ac73bb0e62b249145a8931fd6166bb69 > https://bugs.documentfoundation.org/show_bug.cgi?id=88990 > > > > > > > > > -- > View this message in context: > http://nabble.documentfoundation.org/Discussion-about-highlighting-MS-compatibility-issue-tp4139399p4139552.html > Sent from the Dev mailing list archive at Nabble.com. > _______________________________________________ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice