John, (and Mike,)
I take a different approach to relative size. I needed to keep the relative
size separate from the font size, so I use relative size in
superscript/subscript. It's limited in it's functionality though (only
allows shrinking.) but it serves it's purpose.
That is, I set alternate, unmatching fonts to scale by using the position
tab and 'superscript' or 'subscript' with a "raise/lower" of 1%, then the
relative shrink in the relative size. This results in the scaling value
recorded in the style, not factored into 'font size'.
But it only partially works. Both the Raise/lower and 'relative size' in
the Position tab are unnecessarily limited. Instead of 1-100%,
'raise/lower' should be single number -1000 to +1000. and be a multiplier,
not a percent. (or maybe a percent.) and relative size should be .1% -
10000% If someone is reading this and coding. please consider implementing
a change where "position tab removes the "super/normal/sub" radio buttons
and replaces them with just the variables "raise/lower" and "relative
size". Percent scaling belongs in that spot, not as an instant math typed
into the font size.
That is (here's the technical complaint) I consider it a bug that
<style:text-position> only allows values 1-100 for both of it's values. It
should allow values -1000 to +1000 for the position, and fractional (.01 or
.001) to large (1000 or 10000) for relative size. The "super" and "sub"
should be deprecated or separated. Other than a possible divide by zero,
there's not much risk here. And they are both multipliers, not divisors...
so proper code should already be avoiding the divide by zero.
This provides
1. the ability to set a scaled text without shifting the baseline (even 1%
is sometimes annoyingly noticeable.))
2. the ability to grow text as well as shrink text with the "position" tab
(<style:text-position>).
3. the ability to maintain separate "text scale" vs "font size" so that
upstream changes to the stylesheet roll into all cases properly.
On Fri, Jul 10, 2020 at 4:56 AM mikekaganski <mikekaganski@hotmail.com>
wrote:
Hi John,
What you see is clearly a bug. Even two.
First is a bug of character styles' relative size.
The relative size must evaluate first relative to its inheritance: i.e., if
the character style B (with a relative size) inherits from character style
A, then it needs to apply the relative size to the size defined in that
parent style A (if any). If the size in A is defined, and is absolute, then
the result is an absolute size independent from any paragraph settings;
e.g., if A defines 14 pt, and B defines 150%, then text styled B must be 14
pt * 150% = 21 pt. This case now works correctly.
But if A does not define a size; or if it also defines a relative size -
then the resulting character style as a whole defines a relative size (in
case A has 40%, and B has 150%, the resulting relative size is 40% * 150% =
60%). Then the multiplier must apply to the size defined in the text run's
superordinate. It might be another text run (the ODS defines that character
styles may nest - so this character style may be applied to some part of
text having another character style, and then the size of that
superordinate
text run must be the base to which the multiplier must apply). Or it might
be the paragraph - and now the paragraph should define the base for
applying
the percentage. And here we have the bug #1.
The other bug is that there's a possibility to define Default Paragraph
Style (or any paragraph style that doesn't inherit) to have a relative
size.
That is definitely a bug, since there's nothing in any standard, or in any
setting, that would tell then which is the basis to which the relative size
is applied. And LO behaves erratically then: say, set default paragraph
style to 6 pt; see how everything becomes small, and default is 6 pt. Now
set default paragraph style to 150%; see how everything increases, and
paragraphs of default style are 9%. So it looks like it applied the ratio
to
the old value - but the paragraph style's properties still show the
relative
size, not 9 pt which it should! This is the bug #2.
It all needs bug reports (one for each bug).
A note: there's no UI for nesting character styles, and so my description
about nesting them can't be tested without direct editing of ODF. See
https://bugs.documentfoundation.org/show_bug.cgi?id=115311.
--
Sent from:
http://document-foundation-mail-archive.969070.n3.nabble.com/Users-f1639498.html
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.