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
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?
[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
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.
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' ;-)
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.
I would like to take a look into this.
I'am interested in this bug, can i work on it ?
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.
Thank you very much for information Jordan :) Looking forward to solve this!
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;
Inherited from OOo! Please consider: <http://wiki.documentfoundation.org/BugReport_Details#Version>
@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=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?
(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.
@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 (<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.
*** Bug 63942 has been marked as a duplicate of this bug. ***
@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
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 :)
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
Active development on this bug has started :)
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...
*** Bug 73414 has been marked as a duplicate of this bug. ***
*** Bug 79796 has been marked as a duplicate of this bug. ***
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?
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.
@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?
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.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]
Notes for unit test writers: Revert has to be done manually.