Issue 1601

Summary: Provide change case for: Toggle case, First Letter Capitalized and Sentence case
Product: Writer Reporter: burnus <burnus>
Component: formattingAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@sw <issues>
Severity: Trivial    
Priority: P4 CC: ace_dent, christoph.lukasiak, drichard, frank.loehmann, frank.meies, issues, kami911, khirano, max.odendahl, nesshof, ooo, orw, pelloux, pescetti, stp, thb
Version: 633Keywords: rfe_eval_ok, usability
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: PATCH Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 94586    
Description Flags
new source file to add in 'i18npool/source/transliteration/'
svn diff output
updated patch
new source file containing sentence_case transliterator
new header file containing sentence_case transliterator
Minor patch to left the uppercase letters unchanged
pepp->tl : ui changes listing none

Description burnus 2001-08-31 23:05:13 UTC
The context menu Character/case should have besides the not working lowercase
and uppercase items these two items:
- toggle case: All capitalized letters are converted into lowercased and vice
- First Letter Capitalized: Capitalize the first letter of every word, and make
the other letters lowercase
Comment 1 stefan.baltzer 2001-09-04 10:43:47 UTC
Reassigned to Falko.
Comment 2 falko.tesch 2001-10-10 17:22:50 UTC
I will get back to this issue asap
Comment 3 falko.tesch 2003-10-06 11:41:11 UTC
"Sentence case."
"Title Case"
to the "Format - Case/Characters" menu.
Comment 4 bettina.haberer 2003-10-24 09:36:58 UTC
Considered for 'Office Later'.
Comment 5 2004-09-14 11:17:39 UTC
reassigning & adding keywords according to new RFE process - sophie
Comment 6 josselin 2005-01-29 01:24:24 UTC
a shortcut should be available for that funtion. In MS Office, Maj F3 is used to
toggle between the different case status (UPPER, Upper/lower, lower, First Of
All Word Is Cap) and is really convenient.
Comment 7 lars 2005-12-23 16:58:10 UTC
*** Issue 48720 has been marked as a duplicate of this issue. ***
Comment 8 fabiohenrique 2005-12-27 04:11:01 UTC
Would be interesting also to place this new option in the menu ' Format->Change
Case ' and context menu ' Case/Characters '. ( I don't know why it has different
names ('Change Case' and 'Case/Characters') if they are the same functions )

Comment 9 kieser 2005-12-28 11:18:34 UTC
Not to forget a right-click context menu entry too! Probably the most widely
used means of case-change!
Comment 10 lars 2006-01-17 17:30:40 UTC
*** Issue 60702 has been marked as a duplicate of this issue. ***
Comment 11 ace_dent 2006-01-30 21:30:13 UTC
Corrected spelling in Summary.
Would suggest (to the owner) changing summary to avoid duplicates:
"Provide: Toggle case, First Letter Capitalized and Sentence case"

Comment 12 ace_dent 2006-01-30 21:50:45 UTC
*** Issue 61339 has been marked as a duplicate of this issue. ***
Comment 13 ace_dent 2006-01-30 21:58:04 UTC
*** Issue 54632 has been marked as a duplicate of this issue. ***
Comment 14 ace_dent 2006-01-30 22:04:23 UTC
*** Issue 30132 has been marked as a duplicate of this issue. ***
Comment 15 ace_dent 2006-01-30 22:12:06 UTC
*** Issue 24780 has been marked as a duplicate of this issue. ***
Comment 16 ace_dent 2006-01-30 22:18:47 UTC
*** Issue 41457 has been marked as a duplicate of this issue. ***
Comment 17 ace_dent 2006-01-30 22:25:34 UTC
In the duplicate Issue 41457, a useful analysis of the feature is described by
'mkol'. I have copied this in below, to collect these points in one place.
Furthermore, Issue 41938 (by 'mkol') discusses the need for non-persistent case
formatting and is clearly related.


From 'mkol':

OOo 1.1 writer contains many options for changing character cases. These 
options are scattered at different places and are in varying forms. e.g. 

Format -> Case/Character -> Uppercase
Format -> Case/Character -> Lowercase
For Non Asia Languages like English only these 2 are selectable. It gives 
false impression to the New users that writer has only these 2 case options.

Format -> Character -> Font Effects -> Effects -> Capitals (A Redundant Entry)
Format -> Character -> Font Effects -> Effects -> Lowercase (A Redundant Entry)
Format -> Character -> Font Effects -> Effects -> Title
Format -> Character -> Font Effects -> Effects -> Small Capitals

Will Not user interface be more consistent and clear if all these option are 
put together, Redundant Entries are removed and some more case options are 
provided. e.g.

Format -> Case/Character -> Without (To remove other case options)
Format -> Case/Character -> UPPERCASE (Menu option also written in uppercase)
Format -> Case/Character -> lowercase (Menu option also written in lowercase)
Format -> Case/Character -> Title case ( Menu option also written in title 
Format -> Case/Character -> Small Capitals ( Menu option also written in small 
Format -> Case/Character -> Sentence case (New feature, First character of 
sentence capital, rest characters small, Menu option also written in sentence 
Format -> Case/Character -> tOGGLE cASE (New feature, Aaa Bbb -> aAA bBB, Menu 
option also written in toggle case)
Format -> Case/Character -> Other Options for Asian Languages etc.
Comment 18 ace_dent 2006-02-08 12:02:07 UTC
Note: Toggling Case by pressing Shift+F3, is covered by Issue 12454.
Comment 19 andypep 2006-04-28 09:28:25 UTC
Please distinguish between functions that change the underlying data and those 
which apply effects. The two cases are both useful in their own place. 
When combining and splitting documents, promotion and demotion of titles can 
be done easily with styles when the Font Effects specify the capitalisation. 
But to fix errors when the Caps Lock key was left on need permanent changes to 
the data. 
May I suggest that permament change functions should be under the Edit menu 
only. Leave Format for application of formating techniques and styles. 
Comment 20 geofffarrell 2006-04-28 13:31:56 UTC
I misunderstood andypep's comments at first, so I'll explain what I thought was
meant, to save others any possible confusion. The reference to 'fix errors when
the Caps Lock key was left on' refers to the tOGGLE cASE feature, I think. It
would seem that if one wanted to fix that, it's most likely that changing the
underlying data with the Edit menu is the best way to go. It follows that the
other features should be associated with Font Effects. I agree.

This is an old issue, and it looks as though development has overtaken events
somewhat. In the current version of OOo, Font Effects can handle all the
features requested in this issue, but for Sentence Case. Add that, and this
issue could be closed.  Surely that shouldn't be too hard - just implement it
like Title case, but only change the first word in the sentence, not all words.

Correct me if I'm wrong, but in mkol's analysis, the actions in (1) are achieved
by direct editing, which supercedes the present style's settings, but only where
the direct editing has been made, not in other text that has the same style set.
 The actions in (2), however, become part of the style, and so are implemented
in all parts of the text that carry that style. This means that the two actions
(setting upper/lower case) are not redundant; they have quite distinct purposes.

Well, I just checked, and it seems to work this way with Format->Change
Case->Uppercase, but not with Format->Change Case->Lowercase. For some reason,
the latter has no effect on text set with Title case in the style. Is this
another bug?
Comment 21 discoleo 2006-06-20 13:39:25 UTC
I have posted in issue a
more comprehensive way for casing functions.

Basically, one should be able to customize the casing this way:
 - separate the casing for:
   - character starting a new sentence
   - character starting a new word
   - character inside a word
 - and available options:
   - CASE_NOP: NO Operation, leave case unchanged
   - CASE_UPPER: uppercase
   - CASE_LOWER: lowercase
   - CASE_TOGGLE: toggle case
   - CASE_CUSTOM: some custom casing function

This way, someone may choose to apply:
but others may use WORD_INSIDE: CASE_NOP, and so on.

See my request for an extended discussion and a C++ proof of concept program.
Comment 22 msandersen 2006-07-06 06:46:57 UTC
I posted an issue on this last year (issue 54867) relating to OOo2, so although
this issue is on OOo1, the issue is still pending.

Relating to the quote from mkol:
Format -> Change Case
I don't know if there's a technical difference in OO between this and
Format -> Character... -> Font Effects tab
It seems the Font Effects in OO override the Change Case, whereas in MS Word, if
I set an Effect like Upper Case, but then go to Change Case, the Character Style
is changed. In OO, this is inconsistent since I can override the Character Style
like Bold, Underline, etc, on the toolbar, and the Chacracter Style is changed,
whereas Change Case doesn't. To the user, there is no difference, nor should
there be.
In other words, this is a separate bug. I haven't made a search if it has been

Regardless, this is such a common function, that they SHOULD appear under Change
Case, and in the representative style suggested above), and they should override
character styles. Else you're saying that Change Case itself is redundant, as is
the Toolbar options, and MS Word has it wrong as well.

So, Format -> Change Case SHOULD have "UPPERCASE", "lowercase", "iNVERT cASE"
(sounds better than "Toggle Case"), "Initial Caps", and "Sentence case".
Comment 23 lohmaier 2006-08-07 00:36:16 UTC
*** Issue 66910 has been marked as a duplicate of this issue. ***
Comment 24 discoleo 2006-08-10 18:14:02 UTC

I discovered that
  TABLE_CELL_START is also useful, and/but different from SENTENCE_START !!

See my comment posted for issue 66344.

OO.o Writer should decide which character group a specific character belongs and
pipeline it to the appropriate casing routine. We should be able to specify a
formatting for any of those 4 groups and create our own user-defined casing
Comment 25 jlcheng 2006-10-10 08:45:20 UTC
Yes, I want to get this feature. But why nobody fixed this? I want to try and
give OOo a patch.
Comment 26 stp 2006-11-27 08:14:18 UTC
*** Issue 23864 has been marked as a duplicate of this issue. ***
Comment 27 stp 2006-11-27 08:16:11 UTC
*** Issue 54867 has been marked as a duplicate of this issue. ***
Comment 28 stp 2006-11-27 08:17:31 UTC
*** Issue 57973 has been marked as a duplicate of this issue. ***
Comment 29 stp 2006-11-27 08:29:08 UTC
*** Issue 65860 has been marked as a duplicate of this issue. ***
Comment 30 stp 2006-11-27 08:33:26 UTC
adjusted summary to catch title case
Comment 31 crxssi 2007-01-17 14:54:55 UTC
Six YEARS!!!  That is how long people have been waiting for this relatively
simple feature to be added to OpenOffice!  I can't tell you how often I have
needed the "initial caps" (first letter of each word) function.  Anybody out
there want to take this on?
Comment 32 kieser 2007-01-18 12:49:19 UTC
A poster above had the solution written but didn't know how to submit the patch
to the OpenOffice team.
Comment 33 immanuelcrc 2007-01-18 16:45:29 UTC
I do not think heckling the developers with the length of the issue is helpful.
It is also not unique. Web developers have been asking for Microsoft to fix the
CSS implementation since IE 5... And it took more than 6 years to get IE 7 from
IE 6, and the box model is still not fixed.

One way to get this fixed is to fund a developer yourself. At least with open
source projects us little people have options besides simply asking the company
to fix something. 
Comment 34 ace_dent 2007-03-08 10:52:04 UTC
*** Issue 75218 has been marked as a duplicate of this issue. ***
Comment 35 ace_dent 2007-03-08 11:07:12 UTC
Summary text changed to reduce duplicates, was: "Character/Case should support
toggle case and First Letter Capitalized (Title Case alike)". CC some developers
to keep this on the radar- hope that's ok. Who should this be assigned to? Cheers.
Comment 36 frank 2007-07-25 08:36:02 UTC
*** Issue 77794 has been marked as a duplicate of this issue. ***
Comment 37 bobharvey 2007-07-29 10:37:43 UTC
I am wondering why this is a WP issue, and not a framework one.
I imagine exactly the same tool would be required in Calc, Draw, and Impress.
Comment 38 ace_dent 2007-10-16 08:26:18 UTC
*** Issue 82642 has been marked as a duplicate of this issue. ***
Comment 39 digitaldjinn 2008-02-01 19:57:22 UTC
Glad this is an option now at least in Writer.
One thing I have noticed with the CASE effects approach to this is that the
actual case of the text does not change permanently.  Only how it is formated
changes.  This is not necessarily a bad thing but users might want to make
changes permanent.  If you copy and paste the text to another program - such as
notepad - you get your same old ugly unstylized uncapitalized text back.  I've
also run into situations where I need to convert the case from UPPER to lower
case before the style applied takes full effect.  I think this would be better
addressed in the change case format menu rather than the Character formatting
box just because it's easier to reach - but it has its use in both places.  I
like having the changes in the Character Format box too because Case can now be
controlled by styles - its just doesn't translate to a new Application when you
copy and paste text.  Keeping it where it is allows Styles to format the Case
exactly how you want it automatically.  
That all being said it would also be nice to give this same functionality to
Impress, Calc, etc.  
Comment 40 frank.loehmann 2008-05-14 08:24:15 UTC
Set target to 3.x.
Comment 41 pesala 2008-06-28 06:33:09 UTC
In WordPerfect, when you convert text to initial capitals, the first letter of each word is 
capitalized, except for articles, prepositions, conjunctions, and some pronouns.

If you want to specify additional capitalization exceptions, you can edit the exceptions 
file. (Mine contains: and by for in is it its of on the this to with)

Ideally, OpenOffice should implement this in the GUI as it does for abbreviations and 
words with two initial capitals in the AutoCorrect interface. 
Comment 42 giopo 2009-02-25 07:46:01 UTC
Very useful feature, please don't wait too much to add it 
Comment 43 drichard 2009-02-25 13:23:34 UTC
Hang in there everyone, we (City of Largo) are coordinating bounties for some
features and this one is next.  I hope to get a patch created in the coming months.
Comment 44 drichard 2009-03-05 15:07:06 UTC
There are a lot of excellent ideas in this issue.  I respectfully ask everyone
on the CC list to create unique issues for those ideas not "Sentence Case".  We
are going to fund this feature, and want to hang the patch on #1601 and then try
and get it hopefully merged. 
Comment 45 drichard 2009-03-20 15:01:45 UTC
adding pepp to issue.
Comment 46 drichard 2009-03-20 15:03:19 UTC
Pepp has created a patch to add this feature.  Attaching now.
Comment 47 drichard 2009-03-20 15:07:39 UTC
Created attachment 61070 [details]
Comment 48 drichard 2009-03-20 15:08:24 UTC
Created attachment 61071 [details]
Comment 49 drichard 2009-03-20 15:09:35 UTC
Created attachment 61072 [details]
new source file to add in 'i18npool/source/transliteration/'
Comment 50 drichard 2009-03-20 15:10:51 UTC
Created attachment 61073 [details]
svn diff output
Comment 51 thb 2009-03-20 15:23:23 UTC
Dispatching issue to hopefully suitable dev owner.
Comment 52 max.odendahl 2009-03-20 15:43:56 UTC
If this is added to Writer, please make sure it also works in draw objects,
notes, etc. so the corresponding shells should be adapted as well IMHO
Comment 53 pepp 2009-03-20 16:23:09 UTC
I'm working on adapting the patch to include mod's comments/remarks
Comment 54 ooo 2009-03-20 21:27:28 UTC
Hi, tremendous amount of work, I've quite a few nitpicks though ;-)

The implementation name must match its usage, e.g. in the sentencecase
ctor we have

    implementationName = "";

which should be 

    implementationName = "";

instead if "SENTENCE_CASE" is to be used as the module name to be loaded
with loadModuleByImplName(). Errm.. did you actually try to run your

sentencecase::transliterate() attempts to throw
a MultipleCharsOutputException in case upper/lower was a one-to-many
mapping. That doesn't work, transliterate() is declared to throw
RuntimeException only. Instead, a one-to-many mapping would had to be
fully processed, while adapting the offset sequence if useOffset==true,
which it is meant for. For examples see other transliterate()

For better readability I suggest to rename class sentencecase to
Transliteration_sentencecase, and in
IMPL_CREATEINSTANCE( Transliteration_sentencecase )
and thus

    &sentencecase_CreateInstance },


    &Transliteration_sentencecase_CreateInstance },

There's no need for
in i18npool/inc/servicename.hxx

in i18npool/inc/transliteration_OneToOne.hxx
Why this definition and therefor have class sentencecase being derived
from class transliteration_OneToOne? Sentencecase does not provide
a oneToOneMapping table, nor does it provide a TransFunc function.

<Transliteration unoid="SENTENCE_CASE"/>
in i18npool/source/localedata/data/en_US.xml may have side effects in
such a way that the LC_TRANSLITERATION element in other locales often
refers to the en_US element and such would inherit this transliteration
as well. I'm not sure at the moment which source code actually uses this
list of available transliterations for what purpose, other than the
i18npool internals. Would had to be investigated.

The new transliteration is probably only suitable for some Western
languages. One might need to answer "what is sentence case?" for other
languages and scripts. A limited set of sentence endings and whitespace
is hard coded and the algorithm would already fail for Spanish language
with its inverted marks starting a question or exclamation.

Instead of hard coded whitespace, the unicode::isWhiteSpace() method
from i18nutil/unicode.hxx should be used.

The bPoint variable should not be reset unless an ALPHA or DIGIT
character was encountered. Use unicode::getCharType() and check the bits returned. In fact, everything
between the last sentence ending and the first ALPHA or DIGIT is in
a weak state and should not be folded at all.

The sentence case transliteration is not applicable to all languages,
for example German where nouns always start with an upper case letter.
Situation with CTL languages might be even more complicated. It's not
clear to me what should happen in such cases.


- casefolding::getValue() should only be called if the character is
  LOWER (for LowerToUpper) respectively UPPER (for UpperToLower).
- Creating a temporary string for each character to be replaced and then
  use dst=dst.replaceAt() is total overkill. Use an OUStringBuffer
  instead for buffer manipulation and return buffer.makeStringAndClear()
  at the end.

aTrans.loadModuleByImplName( moduleName, LANGUAGE_SYSTEM );
LANGUAGE_SYSTEM is questionable. It should be the language attribution
of the selected paragraph or sentence instead, else conversion
upper<->lower may be wrong.

All changes in module binfilter are moot, that's only used to convert
between XML and old binary file format. Basically, what the binary
format didn't know doesn't need to be handled. Especially adding UI bits
like string definitions for menus are superfluous, there's no UI for

Regarding the change in TransliterationWrapper:
That may change usage flow. In case code relied on the old behavior that
calling transliterate() with language attribute would load
a corresponding module if needed even if previously another module was
loaded with loadModuleByImplName(), that code would fail now if the
wrapper was reused and such a ImplName module was loaded before. The
change would need extensive checking of all callers whether such
a situation may happen, and provide means at the wrapper to reset to the
initial state as that currently isn't possible.

Wow, that was a lot, let's hope it didn't discourage you ;-)
Comment 55 pepp 2009-03-20 23:01:53 UTC
wow, thanks for the exhaustive comments. It seems that I have some work to do
before it gets accepted :-)
I'll try to provide an updated patch soon.
Comment 56 thomas.lange 2009-03-23 14:27:40 UTC
tl->burnus: If you ar going to rework the patch please take the ownership of
this issues until you are done with it. After that attach the new version of the
patch and hand it back to me.
Comment 57 pepp 2009-03-24 20:59:18 UTC
Created attachment 61157 [details]
updated patch
Comment 58 pepp 2009-03-24 21:00:00 UTC
Created attachment 61159 [details]
new source file containing sentence_case transliterator
Comment 59 pepp 2009-03-24 21:00:25 UTC
Created attachment 61160 [details]
new header file containing sentence_case transliterator
Comment 60 pepp 2009-03-24 21:08:17 UTC
I updated the patch.
Now sentence case is working in Writer, Impress and Draw (on regular text, notes
and draw-text objects)
I also modified the code detailled in er's comment except :
- the remark concerning Deutsch or Spanish (don't know if I can resolve this by
my own)
- the hard-coded ponctuation (currently only '!', '?', '.' can end a sentence)
- i18npool/source/localedata/data/en_US.xml has been left untouched as I didn't
know what to do with it

I'm waiting for your expert comments :-)
Comment 61 drichard 2009-05-04 17:39:59 UTC
ping, can someone review Pepps latest patch and let us know if more changes are
needed please?    Sentence case is a big help for our users.
Comment 62 thomas.lange 2009-05-05 11:54:21 UTC
tl->drichard: Me and OS already evaluated it some time ago. It was believed that
some things will not work. Basically we guessed that the changes that shoudl
have an effect in the font dialog will not work and thus could be dropped.
But since we are not completely sure about out guess, we decided to actually
apply the patch and see if it does work or not.
However so far we have not yet found the time to apply those changes and check
them out.

Also if we look at the actual implementation of the case toggling and compared
it with the competitive application (you know which one ;-), it was guessed that
it might not that useful as in the other application. If I remember the
difference was (by just looking at the code) how words with an already starting
character would be handled. But right now since it is already 2 or 3 weeks past
I would actually need to compare again. But anyway, it is not ours to decide
which actual implementation of the case toggling might be more useful to the
user. Thus we would just have accepted and already applied the patch if not for
the issue above.

Looking at my current schedule I will also not have the time to do a sample
implementation of the patch within the next about 3-4 weeks. Thus I bid you to
be patient for a little while longer. But if you get impatient you need to argue
with the release managers about this issue.
Comment 63 drichard 2009-05-05 14:35:14 UTC
drichard->tl:   All of that makes perfect sense.  I think we knew going into
this project/bounty that we would not be able to replicate fully at this time
all of the features in the other product related to changing case.  However, it
seems like even this "baby step" would be helpful to people.  When you get time
to test, just poke us on this issue and let's see if we can work out something.
 Our users ask me about this feature every time I meet with them.  The patch as
it exists would help them most of the time.
Comment 64 thomas.lange 2009-05-06 07:07:43 UTC
tl->drichard: Sure. When we apply the patch OS and I will have a closer look at
the font dialog thingie and then we will also be able to let testers have at how
the case toggling actually works. Then we can come back with comments and,
together with you guys, can decide if it should just be left as it is or if we
should change a little bit more before integrating the patch.

BTW, basically it is a feature I have available in my text editor and I already
missed it for a long time within Writer. 
Thus I'm lucky to finally get it. ^_-
Comment 65 thomas.lange 2009-05-18 12:02:57 UTC
Just to let you guys know that I'm applying this patch to a CWS now in order to
be able to properly evaluate the patch when I'm done with it... 
Comment 66 thomas.lange 2009-05-27 07:16:39 UTC
Ok, about this patch: basically it is fine and will get integrated. However not
yet exactly as you would like it to be (reasons in a second comment later).

First let me ask two further questions:

1) Is it really necessary to have the types TransliterationModulesExtra AND
TransliterationModulesNewExtra? They have the same values and thus I believe it
would be sufficient to have just one of them.

2) About the actual implementation of the tranliteration. In the case where you
select a sentence like "this was Edisons lab." and do the sentence-case
toggeling will make 'the' to 'The' but also gets 'Edisons' to lowercase.
Shouldn't uppercase words left unchanged? Especially since there are languages
beside English that very much make use of upper-case words and for those the
feature seems to be somewhat broken since it may make more trouble than help in
these cases.
Comment 67 thomas.lange 2009-05-27 07:27:46 UTC
Now about the integration:

a) we do need a specification about the UI changes and how the actual
transliteration works. No Spec no approval by QA. If someone is to sum up all UI
changes and gives a detailed explanation of what the actual functionality should
be I'm willing to write the spec from that info if no other is willing to do
this task.

b) currently if we apply this new font effect from the format character dialog
the changes will not be persistent! This is of course because that new font
effect currently neither gets exported nor imported later on.
Thus we have to disable that entry for now in that dialog. That is the code for
all of it will get integrated but the UI entry will be missing for the time
being. The reason for that is that in order to get this setting persistent we
need to do a file format change. And in order to get that done we need to get
approval by OASIS for this! I'm currently in discussion with our members of the
respective OASIS group about how this needs to be done.
What is already clear that a proposal to OASIS for this change needs to be written! 
The last time someone wanted to added such a feature with file-format change (in
that case the overline feature) the patch provider had to write and file the
proposal. Thus be prepared that someone of you guys here may have to do this. Of
course our colleagues from the OASIS team can give you a helping hand for that.
Only later on when the proposal got accepted by OASIS, only then we can make the
new entry in the Format/Character dialog active. Otherwise either the feature
would not be persistent (i.e. about useless) or we would write incopatible ODF
which is not allowed as well.

Comment 68 frank.loehmann 2009-05-27 08:54:06 UTC
Hi Thomas! Maybe Christoph Lukasiak can take the specification part for this
feature. When do you expect to integrate the CWS? (I put him on CC)
Comment 69 thomas.lange 2009-05-27 09:52:46 UTC
TL->FL: Unless for some reason someone wants to hurry this integration of the
CWS will still be some weeks in the future since this is just the very first
task in the CWS, and usually we want to have about 15...
Comment 70 drichard 2009-05-27 18:26:37 UTC
I'm asking what might be a naive question:   I can understand how bold, italic
and overline required OASIS specifics.  They are not part of the physical text
and need a definition for storage.

But as I understand Sentence Case, it's not an attribute; but instead is
physically changing the text characters which can then be saved correctly.  What
conceptual failure I had? :)

What you are describing sounds more like:
<sentencecase> here is foobar text </sentencecase>

But I didn't picture it working that way.
Comment 71 drichard 2009-05-27 19:20:29 UTC
Pepp just explained to me how it works.  This new character style is applied and
it does the work as you typing.  Understand now.  I was not aware of the
robustness of the patch!
Comment 72 pepp 2009-05-27 19:37:56 UTC
tl : concerning your "2 further questions"
1) concerning TransliterationModulesExtra and TransliterationModulesNewExtra : I
cannot check now but if I remember correctly I did that only because the
upper_to_lower transliterator has the 2. But I think only
TransliterationModulesExtra is really used
2) I just checked and my patch is a bit inconsistent on that point. For instance
"call Paul now" would become "Call Paul now" with the code in svxfont.cxx and
"Call paul now" with the code in transliteration_sentencecase.cxx. I guess the
first behaviour is better
Comment 73 thomas.lange 2009-05-28 11:03:22 UTC
I just commited the new/changed file to svn in the CWS tl69:

Sending        configmgr/qa/unit/data/org/openoffice/UI/GenericCommands.xcu
Adding         i18npool/inc/transliteration_sentencecase.hxx
Sending        i18npool/source/localedata/data/en_US.xml
Sending        i18npool/source/registerservices/registerservices.cxx
Sending        i18npool/source/transliteration/
Adding         i18npool/source/transliteration/transliteration_sentencecase.cxx
Adding         offapi/com/sun/star/i18n/TransliterationModulesExtra.idl
Sending        offapi/com/sun/star/i18n/
Sending        offapi/com/sun/star/style/CaseMap.idl
Sending        officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu
Sending        sc/sdi/cellsh.sdi
Sending        sc/sdi/drtxtob.sdi
Sending        sc/sdi/editsh.sdi
Sending        sc/source/ui/view/viewutil.cxx
Sending        sc/uiconfig/scalc/menubar/menubar.xml
Sending        sd/sdi/_drvwsh.sdi
Sending        sd/sdi/outlnvsh.sdi
Sending        sd/source/ui/view/drviewse.cxx
Sending        sd/source/ui/view/drviewsf.cxx
Sending        sd/source/ui/view/outlnvsh.cxx
Sending        sd/uiconfig/sdraw/menubar/menubar.xml
Sending        sd/uiconfig/simpress/menubar/menubar.xml
Sending        starmath/sdi/svxitems.sdi
Sending        svx/inc/globlmn_tmpl.hrc
Sending        svx/inc/svx/svxenum.hxx
Sending        svx/inc/svx/svxids.hrc
Sending        svx/sdi/svx.sdi
Sending        svx/sdi/svxitems.sdi
Sending        svx/source/cui/chardlg.src
Sending        svx/source/items/svxfont.cxx
Sending        svx/source/items/textitem.cxx
Sending        sw/inc/editsh.hxx
Sending        sw/sdi/_textsh.sdi
Sending        sw/sdi/annotsh.sdi
Sending        sw/source/core/edit/editsh.cxx
Sending        sw/source/ui/config/modcfg.cxx
Sending        sw/source/ui/shells/annotsh.cxx
Sending        sw/source/ui/shells/drwtxtsh.cxx
Sending        sw/source/ui/shells/textsh.cxx
Sending        sw/uiconfig/swriter/menubar/menubar.xml
Sending        unotools/source/i18n/transliterationwrapper.cxx
Comment 74 thomas.lange 2009-05-28 11:07:46 UTC
tl->pepp: What I still like you to provide is a minor patch in order for both of
svxfont.cxx and transliteration_sentencecase.cxx to work the same.

And who will be so kind to provide an attachment with the listing of all UI
changes and the description of how sentence-case toggle should work in order for
CLU to draft a spec from that?
Comment 75 pepp 2009-05-29 09:53:04 UTC
Created attachment 62635 [details]
Minor patch to left the uppercase letters unchanged
Comment 76 thomas.lange 2009-05-29 11:10:32 UTC
tl->pepp: patch applied. Works fine now. Thanks!
Comment 77 pepp 2009-06-08 19:07:26 UTC
Created attachment 62862 [details]
pepp->tl : ui changes listing
Comment 78 thomas.lange 2009-06-09 08:18:35 UTC
tl->clu: Can you have a look at the latest attachment and see if you have
anything you need to write a small spec?
Comment 79 thomas.lange 2009-07-22 10:59:08 UTC
TL->FL: As discussed, please take over for review/approval of UI changes.
Comment 80 frank.loehmann 2009-08-14 16:19:27 UTC
TL showed me the current implementation today. Currently only the sentence case
feature is supported. Furthermore the implementation for Format-Character
requires an ODF format extension. So the only thing left is sentence case in the
Format and context menu. The AutoCorrect feature also handles this case today.
So  I think that we need some more like tOGGLE case and capitalize first letter
of each word to create value for the user.

Is it possible to extend the patch in that way?
Comment 81 Oliver-Rainer Wittmann 2009-08-21 13:48:25 UTC
"First Letter Capitalized"/"capitalize first letter" is already supported by OOo.
See Format - Character - Pane Font Effects - list box Effects - entry Title.
Comment 82 Oliver-Rainer Wittmann 2009-08-24 11:09:42 UTC
Discussion with some colleagues reveals that it does not make sense to treat
"Sentence case" and "tOGGLE cASE" as the other font effects.
The already existing font effects are stored as character formatting properties
in ODF as they are specified in XSL-FO. XSL-FO does not contain something like
"Sentence case" and "tOGGLE cASE". A competitive analysis reveals that "Sentence
case" and "tOGGLE cASE" are only user interface actions - the characters are
directly converted.

Thus, I propose the following:
- Implement "Sentence case" and "tOGGLE cASE" as user interface actions - as it
is already done for "Sentence case" in the AutoCorrect. Have corresponding
entries in context menu "Case/Characters", but not in the character format dialog.
Comment 83 thomas.lange 2009-08-24 11:23:35 UTC
TL: Since OASIS team turned down sentence case being part of the file format,
and UX said they need 'toggle case' as well for a complete feature, I will
create a new CWS with only that code from the patch that is needed for modifying
the context menu.
Since toggle case should be a minor task to implement I will take care of that
as well at that time. 

This will probably take place after code freeze for 3.2 or a bit later since
currently there are still 3.2 issues to be fixed.
Comment 84 thomas.lange 2009-08-24 11:26:10 UTC
TL->FL: We need to meet in order to create the required spec since the feature
set to implement is clear now.
Comment 85 thomas.lange 2009-09-15 15:00:25 UTC
Ok, starting over in CWS tl74 now...
Comment 86 thomas.lange 2009-09-23 13:55:41 UTC
Basically implemented now and files are already committed. But the final
decision about the strings for the three menu entries still needs to be made...
Comment 87 ponny 2009-09-23 18:14:28 UTC
I not need font style changes or
Format - Character - Pane Font Effects - list box Effects - entry Title.
I need real case change. (First character upper, All upper, all lower)

-                                 Ponny 
Comment 88 urmasd 2009-09-24 08:14:23 UTC
I agreed. The visual case representation is fine, but what's Writer is missing
is physical case changing. I cannot believe you've meddling with realization of
this trivial and useful feature for 8 years, have you lost a decency?
Comment 89 thomas.lange 2009-09-28 11:48:41 UTC
Comment 90 ponny 2009-09-28 13:09:24 UTC
Can you stop sending me this annoying messages!?

Comment 91 thomas.lange 2009-10-01 12:05:50 UTC
Ok, I was told the new menu entries should read like this:
  - Sentence case
  - lowercase
  - Capitalize Every Word

Fixed in CWS tl74.
Comment 92 mazz0 2010-01-08 10:33:21 UTC
I don't know if this is due to a difference between English English and American 
English, but I was under the impression that certain words, like 'a' and 'in' and 
'of', etc should not be capitalised in Title Case (unless they're the first word 
, of course), eg

The Lord of the Rings

I don't know what rules govern this, maybe there's something on's 
faqs, but it would be a nice option to have.
Comment 93 thomas.lange 2010-02-10 12:17:41 UTC
Link to spec added.
Comment 94 thomas.lange 2010-02-23 13:52:49 UTC
Side note: sentence case toggling will always be somewhat cheesy since it would
depend on proper sentence detection which can't be done by the breakiterator.
Thus there is only a simple solution that looks for '.', '!' and '?' ...
Therefore it usually goes wrong if for example abbreviations are within the
selection. Be prepared ...

tl->sba: please verify.
Comment 95 stefan.baltzer 2010-06-03 14:45:10 UTC
Verified in CWS tl74.
Find test case here:
Comment 96 2010-06-18 17:52:33 UTC
Verified in DEV300m83 with TCS - closing - Sophie
Comment 97 jurf 2010-07-31 06:22:18 UTC
Many thanks, first of all, for having got this done - it's much appreciated.

Alas, in my testing (DEV300m85) the new "Sentence case" and "Capitalize Every
Word" functions are, unless dealing with plain .txt-style text, potentially
destructive - almost certainly if the document contains ligatures, quite likely
if the selected text contains language mark-up, and possibly (depending on the
other two factor) if the new functions are being applied to multiple selections.

The bugs may also be triggered by other kinds of formatting and situations I
haven't tested for.

I've opened a new issue for this
(, with priority P2 and
a suggestion that it be added to the showstoppers for 3.3. There's a host of
test cases and examples attached as an ODT.

Whilst I've got a rough idea of what might be wrong, I'm not a programmer, so
would appreciate more knowledgeable feedback.
Comment 98 floris_v 2010-11-17 23:40:02 UTC
Oddly enough the new features are missing in the Windows version of release
candidate 5 of 3.3.0 330m15 (build 9546). Am I missing something? I understand
that it's fine in the Ubuntu version.