The current styles are pretty plain - generally speaking they are basically just using bold, italics, and size. I suggest making an enhanced set of styles that are nicer looking, mixing color as well as bold, italics, size, underline (or lower border all the way across the screen) If we hope to move people to use styles - they should look nicer and more appealing :) Possible suggestion - I'm willing to work on this if the enhancement is approved for moving forward. https://drive.google.com/file/d/0B2kdRhc960qdN2JSMDhGVDBrS2M/view?usp=sharing
The last change to the default templates was a pretty “safe”, small one [1], because the ESC decided it so, IIRC the rationale was that enterprise users should not be alienated when it comes to the default formatting. [1]: http://cgit.freedesktop.org/libreoffice/core/commit/?id=06299d6c1620e5b2f2a3588d7c93790278397cbd
Sounds reasonable - but doesn't prevent us adding new styles that are prettier. I suggest something like Header1Gr, TitleGr, etc.... I know that's a bit overwhelming and it'd be great if we could filter styles somehow but this would enable us to make a nice green set of styles that would be bolder, prettier, and more demonstrative of character/paragraph styles than what we currently have being used. I know that one thing on the table is allowing "installing style packages" - if we can do that and start hosting tarballs on the template page that has a "package" of styles that users create, that would be a partial solution (although having a default "pretty style" seems appropriate to me) Of course if UX disagrees, this can be closed.
(In reply to Joel Madero from comment #2) > Sounds reasonable - but doesn't prevent us adding new styles that are > prettier. I suggest something like Header1Gr, TitleGr, etc.... It's important to keep in mind that styles first and foremost carry a structural value. That makes it possible to e.g. automatically create a table of contents out of all the headings or to navigate by document sections. Just like you would use the standard elements in CSS, you should use the standard elements in LibreOffice where relevant. (Not to mention that the default style set is already more overwhelming than it should be.) What you're really looking for are themes, which, if we're aiming for full Office compatibility, will have to be implemented sooner or later. Try to encourage a dev with free time to take a look at it. The Calligra guys wanted to work on this as well, so the dev could work together with them. (They did a write-up on themes on https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes, and they were willing to work on it if someone from LibreOffice worked on it as well.) As for a better default template, I feel like better fonts could make a difference. For example, using Open Sans (or the very similar Noto Sans) or Source Sans Pro instead of Liberation Sans (itself a copy of Arial, which in turn is a copy of Helvetica). The problem with that is that Open Sans isn't available on most devices and bundling the font with every document could dramatically increase each document's size... I'm not sure what the right solution here is -- a thought I had was to try and persuade some influential parties (Adobe, Google, Apple, ...) to decide on a modern set of standard fonts (Adobe's Source family is a good candidate), but that would require someone willing to devote a bunch of time to this, with no guarantee of a positive result.
(In reply to Joel Madero from comment #2) > Sounds reasonable - but doesn't prevent us adding new styles that are > prettier. I suggest something like Header1Gr, TitleGr, etc.... Have to agree with Mirek on this part, as we must utilize the default headings so that a user will still be able to create a TOC from the document. > I know that's a bit overwhelming and it'd be great if we could filter styles > somehow but this would enable us to make a nice green set of styles that > would be bolder, prettier, and more demonstrative of character/paragraph > styles than what we currently have being used. Yes i think the green style set looks nice, but bloating the already bloated current list of default document styles wouldnt be the best way to go about it. > I know that one thing on the table is allowing "installing style packages" - > if we can do that and start hosting tarballs on the template page that has a > "package" of styles that users create, that would be a partial solution > (although having a default "pretty style" seems appropriate to me) Yes it would be great to have a style set site, similar to the extensions and templates site, where users are able to submit styles that could be shared with other users. (In reply to Mirek2 from comment #3) > What you're really looking for are themes, which, if we're aiming for full > Office compatibility, will have to be implemented sooner or later. Try to > encourage a dev with free time to take a look at it. The Calligra guys > wanted to work on this as well, so the dev could work together with them. > (They did a write-up on themes on > https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes, and they were > willing to work on it if someone from LibreOffice worked on it as well.) I think he is more likely looking for a simpler solution like MSO Quick Styles (aka style sets), which hopefully will be implemented with the group styles idea from bug 86039. As MSO themes are embedded into documents as standard styles when they are saved, i dont think LO needs to implement themes for compatibility. Reading through the link, i dont think LO will likely implement themes anytime soon as there would be quite a bit of development not only in LO but at the ODF level to achieve it. I have emailed the author of the link to see how far he has gotten with the work mentioned. > As for a better default template, I feel like better fonts could make a > difference. For example, using Open Sans (or the very similar Noto Sans) or > Source Sans Pro instead of Liberation Sans (itself a copy of Arial, which in > turn is a copy of Helvetica). The problem with that is that Open Sans isn't > available on most devices and bundling the font with every document could > dramatically increase each document's size... I'm not sure what the right > solution here is -- a thought I had was to try and persuade some influential > parties (Adobe, Google, Apple, ...) to decide on a modern set of standard > fonts (Adobe's Source family is a good candidate), but that would require > someone willing to devote a bunch of time to this, with no guarantee of a > positive result. We are currently bundling Google's Caladea and Carlito as alternatives to Cambria and Calibri, so we could easily switch to that over Liberation Sans and Serif as the default fonts.
For themes support we could first just add it so that it changes the styles directly with only some predefined and static themes. This would need no change to the file format. Then we can iterate on top of that and add full support step by step. I'll work on a proof of concept.
(In reply to Tomaz Vajngerl from comment #5) > For themes support we could first just add it so that it changes the styles > directly with only some predefined and static themes. This would need no > change to the file format. According to the kde link, we would need to place custom XML tags into an ODF document, so that it is aware that a particular theme has been applied to a document. "Themes are stored separately of documents in dedicated format and versioned. Only for compatibility with other office suites, styles are generated into the document but references to original themes are kept in custom XML tags. This is allowed by ODF." > Then we can iterate on top of that and add full > support step by step. I'll work on a proof of concept.
(In reply to Jay Philips from comment #6) > According to the kde link, we would need to place custom XML tags into an > ODF document, so that it is aware that a particular theme has been applied > to a document. Yes, sure, but at first we don't even to do this. The UI would just not show which theme was selected. Selecting one theme would just change the style values (this would need to be done for ODF 1.2 or older anyway). Just this would already be very beneficial to the user. Anyway, I think we need a new bug for theme support or look-up if there is an existing one.
(In reply to Tomaz Vajngerl from comment #7) > Yes, sure, but at first we don't even to do this. The UI would just not show > which theme was selected. Selecting one theme would just change the style > values (this would need to be done for ODF 1.2 or older anyway). Just this > would already be very beneficial to the user. Yes as a beginning that would be useful to users. > Anyway, I think we need a new bug for theme support or look-up if there is > an existing one. Submitted as bug 90497 as i didnt find any bug report about it.