I had a look at the attached sample file. You still control Writer through its styles (full or reduced capabilities) and these styles are translated, perhaps not as you would like, by an export filter (may be approximate remember: Traduttore, traditore). However, in both cases, you don’t edit directly HTML markup. I conducted my test in the second context. In the second case, you start directly into HTML formatting with simplified styles corresponding to W3C standards. In the first case, you edit a sophisticated formatted document which is converted into an HTML one with embedded CSS directives trying to mimic Writer styles. odt is not the same as File> New> HTML Document then save! ![]() To summarise: no bug in Writer/HTML but a misconception of yours about differences between HTML edition and document edition (and also a different base configuration in those components).ĬAUTION! Save as. They will translate to CSS to be rendered in a portable way by browsers. But you can always define custom ones for your needs. Note that there are far less built-in styles in Writer/HTML component than in Writer. This will translate to CSS and give highly predictable results. It is much better, safer and reliable to use styles (or as a fallback, cursors in the horizontal ruler). This is intended behaviour in browsers.Īnyway, in Writer or browsers, it is always a bad idea to indent paragraph with spaces. However, if you use ordinary spaces for your indent, those spaces are also present in the HTML (Writer takes no initiative about that and you can’t blame it), but W3C says that any sequence of ordinary spaces is considered as a single space and browsers render it accordingly (eventually stretching ALL spaces in a line to justify adge to edge). If indent is made with NBSP, those NBSP are present in the resultant HTML and rendered as expected. ![]() Configure all your levels, notably the separator before and after parameters. Consider they are separate applications settings-wise. The settings you may have customised in Writer are not forwarded to the HTML editor. In that case, you need to translate everything from en-US into a new locale beforeI can accept the PR.You must configure the properties of chapter numbering with Tools> Chapter Numbering. You can review the existing locales and proposed changes/fixes or submit a new locale in a Pull Request. All happens only in the 'locales' directory. That's just another OSS project, we're waiting for your Pull Requests! mach package Want to contribute to BlueGriffon? mach build Run BlueGriffon in a temporary profile
0 Comments
Leave a Reply. |