https://bugs.documentfoundation.org/show_bug.cgi?id=90152
--- Comment #11 from Aaron Reichenbach <[email protected]> --- I've been looking at this bug and I don't think the obvious fix (removing the space before the colon and adding a comma separator) is actually the right solution. It solves the English case but immediately breaks French and other locales that expect a space before the colon. LibreOffice is too internationalization-aware for that to be a good solution, I think. The root problem is that the format string is hardcoded in lcl_FormatPostIt in sw/source/core/doc/doc.cxx: static char const sTmp[] = " : "; And then spaces and commas are hardcoded in when building the string. This single string controls all three text-based print modes (EndDoc, EndPage, Only) and there's no way for users or locales to change it. It's easy enough to fix this to something more visually appealing, but I think it will be unsatisfactory to lots because it will be based upon the aesthetic appeal of the person pushing it instead of something that would be good for every user. I'd like to propose a more complete fix: a user-configurable format string with tokens, similar to how mail merge fields work. Something like: {Page}: {PageNum}, {Line}: {LineNum}, {Author} [{Date}] Where the user defines all the characters around the tokens as they please. If it's a changelog or something, maybe someone wants to priortize date at the front, if it's a legal document, maybe they need author first, etc. Get it working with text only, and then maybe look at being able to style this stuff so comments can work for people how they want. The tokens I'm thinking are: {Page}, {PageNum}, {Line}, {LineNum}, {Author}, {Date}, {Newline}, and {Rule} for a horizontal separator. The default format string could live in the translation files alongside the existing STR_POSTIT_PAGE, STR_POSTIT_LINE, STR_POSTIT_AUTHOR strings, so each locale can define a sensible default. The UI would be a new Printing tab in Format -> Comments, with a text input for the format string, a token insertion helper so users don't have to memorize the syntax, and a live preview. No per-token formatting for now, just plain text layout control. It's quite a bit more significant to add in the formatting stuff than just plain text. Before I go further I wanted to check if this approach makes sense to the maintainers, and whether there's existing infrastructure I should be building on rather than rolling something new. It also kind of changes the scope of this to something quite a bit bigger than just fixing a couple of static strings, so I understand if this becomes "Just fix the one line" and file a separate bug. -- You are receiving this mail because: You are the assignee for the bug.
