[upstream] "Increase font" and "decrease font" could work even if the selection contains differing font sizes

Bug #783383 reported by Nicola Battilani
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
LibreOffice
Fix Released
Wishlist
libreoffice (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: libreoffice

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.
--Nicola

Revision history for this message
In , Bug-1 (bug-1) wrote :

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.
--Nicola

Revision history for this message
In , Tlillqvist-k (tlillqvist-k) wrote :

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?

description: updated
Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

[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:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

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.

Revision history for this message
In , R6btzkgnhs (r6btzkgnhs) wrote :

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' ;-)

Revision history for this message
In , greggory.hz (greggory-hz) wrote :

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.

Revision history for this message
In , Jordan Chin (retroneon) wrote :

I would like to take a look into this.

Revision history for this message
In , Ametrix-bg (ametrix-bg) wrote :

I'am interested in this bug, can i work on it ?

Revision history for this message
In , Jordan Chin (retroneon) wrote :

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.

Revision history for this message
In , Ametrix-bg (ametrix-bg) wrote :

Thank you very much for information Jordan :) Looking forward to solve this!

Revision history for this message
In , Mstahl (mstahl) wrote :

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;
            }
            break;

Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :
Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :
Revision history for this message
In , Bug-1 (bug-1) wrote :

(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.

Revision history for this message
In , Libreoffice-z (libreoffice-z) wrote :

@Nicola:
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 (<email address hidden> or me by mail), but not in the bug, because too many comments not directly related to the report make the Bug muddled.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

You reported this to upstream LibreOffice. Good job! In the future you can actually link this bug to the upstream bug so that it is easier to realize it has been confirmed.

Changed in libreoffice (Ubuntu):
status: New → Confirmed
summary: - "Increase font" and "decrease font" could work even if the selection
- contains differing font sizes
+ [upstream] "Increase font" and "decrease font" could work even if the
+ selection contains differing font sizes
Changed in df-libreoffice:
importance: Unknown → Wishlist
status: Unknown → In Progress
Revision history for this message
In , Joren-libreoffice (joren-libreoffice) wrote :

*** Bug 63942 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Joren-libreoffice (joren-libreoffice) wrote :

@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,
Joren

Changed in df-libreoffice:
status: In Progress → Confirmed
Revision history for this message
In , Danny-w (danny-w) wrote :

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 :)

Changed in df-libreoffice:
status: Confirmed → In Progress
Revision history for this message
In , Björn Michaelsen (bjoern-michaelsen) wrote :

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

Revision history for this message
In , Danny-w (danny-w) wrote :

Active development on this bug has started :)

Revision history for this message
In , Danny-w (danny-w) wrote :

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...

Changed in df-libreoffice:
status: In Progress → Confirmed
Revision history for this message
In , Jorendc (jorendc) wrote :

*** Bug 73414 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Momonasmon (momonasmon) wrote :

*** Bug 79796 has been marked as a duplicate of this bug. ***

Revision history for this message
crysman (crysman) wrote :

It's not an "enhancement", I consider it a bug. If its working in MS Word, it should work here, too. This feature is almost useless until not working with multiple paragraphs...

If you are willing to fix it, please, consider make it customisable (the step) - not just default 2 or how many it's there now...

Revision history for this message
In , D-sikeler94 (d-sikeler94) wrote :

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?

Revision history for this message
In , Jim Cobley (jimc-6) wrote :

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.

Revision history for this message
crysman (crysman) wrote :

@jimc-6:
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?

Revision history for this message
In , crysman (crysman) wrote :

@jimc-6:
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?

Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

Daniel Sikeler committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98c95ce3a759a6f691c20cb1e376fa54a9dfdbc0

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Changed in df-libreoffice:
status: Confirmed → Fix Released
Changed in libreoffice (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.