Bug 57397 - FORMATTING: Writer & Impress – capitalize every word works not after quotation mark
Summary: FORMATTING: Writer & Impress – capitalize every word works not after quotatio...
Status: RESOLVED DUPLICATE of bug 63432
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: Other All
: low minor
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-22 07:39 UTC by bugquestcontri
Modified: 2014-06-21 14:42 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
writer file with example and explanation (10.58 KB, application/vnd.oasis.opendocument.text)
2012-11-22 07:39 UTC, bugquestcontri
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugquestcontri 2012-11-22 07:39:00 UTC
Created attachment 70412 [details]
writer file with example and explanation

Problem description: 
Writer and Impress behave the same way.

When a test string is selected and the command “capitalize every word” is use, Words starting after a quotation mark are not capitalized.


Steps to reproduce:
1. wirte a text string in quotations marks
2. select text string including quotation marke
3. use command "captilize ecery word"

Current behavior:
first character after quotation mark is not capitalized

Expected behavior:
first character after quotation mark is capitalized like all the others in selected string including quotation marks


Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0
Comment 1 A (Andy) 2012-11-24 09:51:13 UTC
reproducible with LO 3.6.3.2. (Win7 Home, 64bit)

reproduced by the following steps:
1. open WRITER or IMPRESS
2. write any text string in quotation marks
3. select the text string including the quotation marks
4. go to FORMAT -> CHANGE CASE -> CAPITALIZE EVERY WORD

If the text is not in quotation marks then the function works correctly and it also works correctly if only the text without quotation marks is selected.
This means that LO interprets the first quotation mark as the first character and there is no uppercase available in this case.  This behaviour is in principle comprehensible and also correct, but maybe it is possible to find another solution for this specific situation?  But I am also not sure, if there will be in this case other situations where you would need exactly the current behaviour?
Comment 2 bugquestcontri 2012-11-24 11:14:46 UTC
Thanks for testing on a different platform and LibO version

It would be very helpful if the quotation mark would be neglected and the following character would be changed to upper case.

I hate to say so, but MSO is neglecting the quotation mark and this makes work easy.
Comment 3 Florian Reisinger 2013-04-21 07:25:17 UTC
I can confirm this with Version: 4.1.0.0.alpha0+
Build ID: fa72fc3eddbfabb82193452a4ba993b11d1584d
TinderBox: Win-x86@6, Branch:master, Time: 2013-04-18_23:11:53 and Word 2010
Comment 4 bugquestcontri 2013-04-25 09:19:26 UTC
I can confirm the bug in

Version 3.6.6.2 (Build ID: f969faf)
and
Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)

XP/SP3
Comment 5 tommy27 2014-06-04 04:48:48 UTC
see also Bug 79605 - FORMATTING: capitalization of first word doesn't work in sentences within quotes

I think they have the same root... 

probably the " is seen as the first letter and capitalization is applied to that (but you won't notice it since there's no visual difference between an " in upper or lower case) instead of following letter
Comment 6 tommy27 2014-06-04 05:08:21 UTC
problem is not limited to just the quotation mark but to other symbols as well.

I mark this as a duplicate of 63432... I know that that one was filed later but IMHO has more complete description and better test file highlighting many different scenarios

*** This bug has been marked as a duplicate of bug 63432 ***
Comment 7 bugquestcontri 2014-06-21 14:42:26 UTC
I made again a test in Version: 4.2.4.2
Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8

Bug is still the same. I also can confirm comment6 from tommy27 that the bug also appears for other symbols.