Bug 35862 - "Increase font" and "decrease font" could work even if the selection contains differing font sizes
Summary: "Increase font" and "decrease font" could work even if the selection contains...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: d.sikeler94
Whiteboard: target:4.4.0 unitTestNotes:29
Keywords: difficultyInteresting, easyHack
: 63942 79796 (view as bug list)
Depends on:
Reported: 2011-04-01 03:39 UTC by Nicola Battilani
Modified: 2023-10-18 17:08 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Nicola Battilani 2011-04-01 03:39:27 UTC
Hi all!
 Why "increase font" and "decrease font" from the formatting toolbar can't manage block of text of various font size?

 To reproduce this, just make visible "increase font" and "decrease font" on the formatting toolbar, then write some text and change size only to a part of it. If you now select all what you wrote, you'll be no more able to use those buttons.

 It could be very useful, especially when we have to fit piece of text already formatted over spaces predefined, such as articles, etc.

Thanks to all over the community for such a useful software.
Comment 1 Don't use this account, use tml@iki.fi 2011-05-10 23:34:39 UTC
Something that, as you say yourself, "could be very useful", is hardly of "high" importance. Also, this is clearly an enhancement request, not a bug report. I agree it would be very useful, sure. Perhaps this could be an EasyHack?
Comment 2 Björn Michaelsen 2011-12-23 11:43:18 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 3 Björn Michaelsen 2011-12-23 12:57:26 UTC
An EasyHack should have been checked by developers and thus is confirmed regardless of age. Moving back to NEW from NEEDINFO again. Sorry for the hassle.
Comment 4 taka khumbartha 2012-01-05 16:34:18 UTC
I agree this would be a nice feature to implement, it is especially useful for old documents or imported documents that may not already be formatted using Styles.

And I do believe it fits the category of "bug" as well.  The functions are called 'Increase Font' and 'Reduce Font', not 'Increase just this font size' and 'Reduce just this font size' ;-)
Comment 5 Greggory Hernandez 2012-02-04 08:48:01 UTC
Where would someone interested in working on this find the relevant code (whatever code is run when either button is clicked)? I haven't got any experience with the libreoffice code base and it is slightly overwhelming to try and decide where something like this might hide. Any help would be greatly appreciated.
Comment 6 Jordan Chin 2012-03-13 20:09:45 UTC
I would like to take a look into this.
Comment 7 Ahmed 2012-03-21 11:10:10 UTC
I'am interested in this bug, can i work on it ?
Comment 8 Jordan Chin 2012-03-25 11:11:56 UTC
Ahmed, as this should not be a difficult bug, if you are able to complete it, go ahead with this. I was not able to get very far and have emailed the mailing list with my current findings (as of this time it was caught by the auto-spam filter so is awaiting a moderator's eye). Until then I'll keep moving forward with this.

So far I have found that the ID of the button is something like FN_GROW_FONT_SIZE, and from that the code that is run whenever it is clicked. However, I have not found what decides whether the button is enabled or disabled. Since this functionality is available in Impress (but not Writer), maybe if we take a look at the difference we can solve this bug... but that's all I have found so far.
Comment 9 Ahmed 2012-03-26 12:06:04 UTC
Thank you very much for information Jordan :) Looking forward to solve this!
Comment 10 Michael Stahl (allotropia) 2012-04-02 05:14:04 UTC
well yes the UI for this is disabled because the core can't actually do this,
so just enabling it in the UI won't be very useful.

this needs a new SwDoc function that iterates over the text attributes
(SwTxtAttr) in a selection (cursor/SwPaM), reads the font size at
every range that is spanned by a TXTATR_CHARFMT, TXTATR_AUTOFMT or
TXTATR_INETFMT attribute, then increments/decrements that and
sets a new AUTOFMT (or just a CHRATR_FONTSIZE) for that range.

oh wait, of course it's necessary to handle CHRATR_FONTSIZE set
at SwTxtNode as well... i forgot if it's possible to have that
at all when formatting text attributes exist...

so this doesn't look "easy" to me, more like "interesting" :)

quoting from mmeeks on the mailing list, the UI is disabled here:

sw/source/ui/shells/txtattr.cxx (SwTextShell::GetAttrState)
            case FN_GROW_FONT_SIZE:
            case FN_SHRINK_FONT_SIZE:
                SvxScriptSetItem aSetItem( SID_ATTR_CHAR_FONTHEIGHT,
                                            *rSet.GetPool() );
                aSetItem.GetItemSet().Put( aCoreSet, sal_False );
                if( !aSetItem.GetItemOfScript( rSh.GetScriptType() ))
                    rSet.DisableItem( nSlot );
                nSlot = 0;
Comment 11 Rainer Bielefeld Retired 2012-06-16 22:31:34 UTC
Inherited from OOo!
Please consider:
Comment 12 Rainer Bielefeld Retired 2012-12-17 15:30:11 UTC
@Nicola Battilani
It's a little annoying ... .

What do you think about doing something useful? For example, you could check these
<https://bugs.freedesktop.org/buglist.cgi?f1=cc&emailreporter1=1&list_id=188239&o1=notsubstring&emailtype1=substring&chfieldto=Now&query_format=advanced&chfieldfrom=-60d&bug_status=UNCONFIRMED&email1=LibreOffice%40bielefeldundbuss.de&v1=%40&product=LibreOffice> bugs and  try whether you can confirm one of them?
Comment 13 Nicola Battilani 2012-12-17 15:45:23 UTC
(In reply to comment #12)
> @Nicola Battilani
> It's a little annoying ... .
> <http://wiki.documentfoundation.org/BugReport_Details#Version>
> What do you think about doing something useful? For example, you could check
> these
> <https://bugs.freedesktop.org/buglist.
> cgi?f1=cc&emailreporter1=1&list_id=188239&o1=notsubstring&emailtype1=substrin
> g&chfieldto=Now&query_format=advanced&chfieldfrom=-
> 60d&bug_status=UNCONFIRMED&email1=LibreOffice%40bielefeldundbuss.
> de&v1=%40&product=LibreOffice> bugs and  try whether you can confirm one of
> them?

 Ok. Sorry, I didn't get the point of your previous comment. What do you think: should I change the version entry to 3.5.0? Anyway, I think the the link you put from the wiki is talking about bug. For sure, an enhancement is related to each of the previous versions.

 Thanks for the suggestion to check other bugs. I'm going to give a look.
Comment 14 Rainer Bielefeld Retired 2012-12-17 16:37:03 UTC
From user's view it's interesting to know when a bug will be fixed, but from developer's view it's important to know when the problem started. Here is less important because most people know, but for someone who stumbles in here it might look like a regression with a 4. version, and so I changed back.

Thank you for your interest, if you have further questions you should ask on  mailing list (<libreoffice-qa@lists.freedesktop.org> or me by mail), but not in the bug, because too many comments not directly related to the report make the Bug muddled.
Comment 15 Jorendc 2013-04-26 20:43:21 UTC
*** Bug 63942 has been marked as a duplicate of this bug. ***
Comment 16 Jorendc 2013-04-26 20:45:55 UTC
@Jordan Chin: I reset the "Assigned To" field + bug status. Following the history you are assigned more then a year now. I'm freeing this bug, so others can work on it. If you are working on it, or would like to work on it again, please feel free to re-assign.

I hope you understand.

Kind regards,
Comment 17 Daniel Brown 2013-10-03 01:50:43 UTC
I've assigned this bug to myself, and will undertake development this week. I've read the above comments and tips and will report back if I experience any difficulties :)
Comment 18 Björn Michaelsen 2013-10-04 18:46:30 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 19 Daniel Brown 2013-10-17 06:32:40 UTC
Active development on this bug has started :)
Comment 20 Daniel Brown 2013-11-12 14:35:41 UTC
Sorry, going to have to let this part of the project go. My University final year project has taken more and more of my time recently, and that has to come first...
Comment 21 Jorendc 2014-01-14 17:23:35 UTC
*** Bug 73414 has been marked as a duplicate of this bug. ***
Comment 22 Maxim Monastirsky 2014-06-18 11:41:59 UTC
*** Bug 79796 has been marked as a duplicate of this bug. ***
Comment 23 d.sikeler94 2014-09-10 08:43:08 UTC
In Impress the function is already implemented. When you select text with different sizes and then press the button all the text get the same size (smallest of the selected text) in the first step. Afterwards you can increase or decrease the size. Is this the way it should be done in Writer as well? An other way to handle this, would be to increase or decrease every part with the same size independent from the other parts.
When should the button be disabled? When any part of the selected text already has the smallest/biggest size? Or when all the text has the smallest/biggest size?
Comment 24 jim 2014-09-10 09:15:15 UTC
As the function is to "Decrease" or "Increase" font size it should do 
what it says - that implies it must NOT change all characters to the 
same size!
I gather then that "Impress" could annoy me a LOT?

The button could be disabled if a multi sized string is selected because 
it is likely to be a little used feature but if it exists it could be a 
useful feature for some.
The button should be disabled if one of the character sizes couldn't be 
increased or decreased further - ie if pressing it would not provide the 
expected function.

Thinking further it could be handy for changing font size if I had a 
whole paragraph with a bold/large header line - great now that's 
embedded in my expectaion when I hadn't considered it before.
Comment 25 crysman 2014-09-14 18:38:50 UTC
you say: "...The button could be disabled if a multi sized string is selected because it is likely to be a little used feature..."

I highly disagree. Moreover, I consider it right opposite - it is the very core feature. Just imagine you want to make your document fit into 4 pages instead of 5. With here being discussed feature properly implemented (or in MS Word), it is just question of Ctrl+A and <your_shortcut_to_decrease_font_size>. Done. On the contrary... I am asking: how you do it so effectively now in current implementation?
Comment 26 Commit Notification 2014-11-03 11:27:28 UTC
Daniel Sikeler committed a patch related to this issue.
It has been pushed to "master":


fdo#35862 De-/Increase font when multi-sized text

It will be available in 4.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 27 Robinson Tryon (qubit) 2015-12-16 05:27:13 UTC
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting)
Comment 28 Robinson Tryon (qubit) 2016-02-18 16:37:09 UTC
Remove LibreOffice Dev List from CC on EasyHacks
(curtailing excessive email to list)
Comment 29 Buovjaga 2023-10-18 17:08:38 UTC
Notes for unit test writers:

Revert has to be done manually.