Description: Character styles are dependent on other character styles, i.e. modifications in attributes are relative to the character style they inherit from. Under various circumstances, it is necessary that the modification be applied to the attribute definition in the current paragraph style. As an example, consider a character style which changes the font face. Even inside a consistent family, the x-height may be visually different among variants of the same face leading to unpleasant results. The font size needs adjustment, say 80%. If 80% is entered as the font size, it will be computed ultimately against Default Character Style (a fake style) which will take the value either from Default Paragraph Style or from Tools>Options, LibreOffice Writer>Basic Fonts (Western). The size is then fixed and does not depend on the paragraph style. The font size may be tuned for Text Body but if the character style is used in a Footnote, the word will be too big compared to the rest of the note. As a workaround, I don't play with the font size, leaving it in its "transparent" state so that the one from the paragraph style applies, but I change the Position parameters, using Superscript and 80% Relative font size. Ideally Raise/lower by would be set to 0%. Unfortunately, Writer doesn't accept this no-op value and corrects to 1%. Of course, the same applies to Subscript. Even such as small offset is noticeable, though it mitigates at high magnification (perhaps an effect of quantization of integer arithmetic in the renderer). To completely eliminate the non-alignment of the base line, I'd like to be able to set Raise/lower by to 0%. Steps to Reproduce: 1. Format a character as 1% superscript and size 100% (for better comparison) in the middle of a word 2. Display at zoom level 100% Actual Results: On my screens (96 dpi), the superscript characters are offset one pixel. The word looks jaggy. The effect is less visible with other zoom factors. Expected Results: To avoid such jagginess, I'd like to set Raise/lower by to 0% Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Tested with 7.0.5.2 but floor to factor is present in any release UI render: default VCL: kf5 OS: Linux 5.11.7 Distro: Fedora 33 (x86_64) KDE Plasma: 5.20.5 Qt: 5.15.2
Created attachment 170621 [details] Sample showing jagginess
(In reply to ajlittoz from comment #0) I can't see the problem in the document and I've also tried with a new document on my own. Besides that I prefer to concentrate on bugs and not on improving workarounds for bugs. But there might be different opinion from someone else. Additional infomation: Font percentage in character styles has its limitations (see bug 99544)
It isn't a bug per se. It is a limitation in the range of allowable values. The lowest possible value is 1%. This is probably not noticeable on print (because printers are usually 600dpi; even at 300dpi it should be acceptable). However, on screen, depending on zoom factor, a run of 1% superscript characters can be vertically offset one pixel. And this is visible, giving the jaggy appearance. The cause is integer rounding to nearest pixel size. Allowing a minimal value of 0% would fix the issue, at least in my use case. I perfectly understand that a 0% superscript is nonsense as a superscript. In my case, it is a trick to work around the fact that character style are not defined against paragraph style but against their character style ancestor. With the 0% superscript position, I can apply a %-size to the paragraph style size without changing the base line. Thus it is not a bug fix but an augmentation of the allowable range. The present range is 1% to more than 13999% ! Note that a 13999% is nonsense because it pushes the base line beyond the bottom margin and makes it disappear unless the page height is really large. My request is only to allow 0% to<whatever maximum you deem acceptable>. I also approve your intent to concentrate on bugs. Resources are so limited. Anyway, I am really grateful for the tremendous job which has been done and would like to be skilled enough to contribute. Is there any design documentation which could serve as an introduction to LO internals?
Likely not so easy; changed the UI to be able to enter 0% and that makes the character disappear.
(In reply to Heiko Tietze from comment #4) > Likely not so easy; changed the UI to be able to enter 0% and that makes the > character disappear. Very strange indeed. Have you any idea about the cause?
Not so strange to me. There are thousand of lines producing the layout, and zero sub/superscript is probably at some point a multiplication with 0. This setting is what Normal means. => WF Moreover, your idea to manipulate attributes to make two different fonts visually similar sounds wrong to me.
(In reply to Heiko Tietze from comment #6) > Moreover, your idea to manipulate attributes to make two different fonts > visually similar sounds wrong to me. You're right I'm abusing Writer features but only as a work around against a design limitation. I want to mix in the same paragraphs two font which visually have not the same x-height though they come from the same font designer. To have a nice look, I need to set font size to 80% of the one used in the paragraph. As you know, character style font size can be set relative to their ancestor character style font size, not paragraph style. Thus, I can tune font size to be used with Text Body (e.g. 10pt vs. 12pt). But when I use the character style in a footnote, I still have 10pt vs. 10pt which breaks the intent. The only circumstance where a character style may be made relative to a paragraph style is super/subscript. This is why I abused the feature. Unfortunately, I can't get baseline continuity because the offset is 1% at least. I perfectly know this is a hack and an ugly one. It is an abuse. But I can't see any other solution. Design-wise, I see no solution. Character styles must be defined relative to each other (as are paragraph styles). However there are cases where some attributes need to be defined relative to the paragraph style where they'll be used. This is a dynamic behaviour and I imagine this would be a hell of a nightmare to implement (deferred style configuration until it is used; different configuration in different occurrences cascading to other dependent character styles, …) not speaking of the acceptance of such a feature in ODF. Eventually, could not Default Character Style be considered as a placeholder for the attributes in the paragraph style? Character styles defined independently from Default Character Style keep their present "combat-proven" properties. Those defined as modification of Default Character Style would be relative to the Paragraph Style. Not speaking of implementation issues, does this make sense (at least for font size as I don't see applications with the other attributes)? Ideally, I would like negation of bold, italic, underline, … but these are not binary attributes because modern fonts may have a wide range of weights and "italic" does not imply slanted (italic just means a different kind of shape). So, no solution on these apart from some introspection macro instead of checkboxes. But then, again an implementation nightmare. I should perhaps start to learn LaTeX.
(In reply to ajlittoz from comment #7) > Eventually, could not Default Character Style be considered as a placeholder > for the attributes in the paragraph style? As a consequence, all CS would have to be specified in percent. Many users are used to font size in points, like 12pt and 10pt, and need a calculator to get the correct value. And ultimately I believe it will not solve your problem. But why don't you create an extension, maybe per direct formatting? > I should perhaps start to learn LaTeX. Or C++, and implement this feature in LibreOffice :-)
(In reply to Heiko Tietze from comment #8) > implement this feature in LibreOffice :-) I admit I'm a bit tempted, but the code size is really huge. Is there any design documentation describing the implementation principles (class semantics and others)? Should I start by reading ODF? I must also tell I don't like autogen and m4. I prefer CMake.
(In reply to ajlittoz from comment #9) > I admit I'm a bit tempted, but the code size is really huge. Wrote some blog posts how to do the first steps https://design.blog.documentfoundation.org/2018/02/22/easyhacking-set-environment/ https://design.blog.documentfoundation.org/2018/02/28/easyhacking-all-about-terminology/ https://design.blog.documentfoundation.org/2018/04/14/easyhacking-how-to-make-a-feature-optional/ If it comes to document filters, visualization of content, data processing, etc. you need to dig through 10M lines of code that has grown over many years. But developers are very kind and help in case of questions. And sooner or later we will have a development mentor.
(In reply to Heiko Tietze from comment #10) > you need to dig through 10M lines of code Is there an LXR or Grok site? Otherwise as LXR administrator I can create one.
Don't reply to my last question. I found opengrok.libreoffice.org Don't know how to make my previous comment "no longer relevant".
(In reply to ajlittoz from comment #12) > Don't reply to my last question. I found opengrok.libreoffice.org > > Don't know how to make my previous comment "no longer relevant". https://opengrok.libreoffice.org/ https://github.com/LibreOffice/core and more help at https://wiki.documentfoundation.org/Development
(In reply to ajlittoz from comment #12) > Don't reply to my last question. I found opengrok.libreoffice.org > > Don't know how to make my previous comment "no longer relevant". Tag it as "obsolete". But since I read incoming messages from ux-advice your flag might come too late for me. It's rather something for people who skim over the thread in BZ.