Reassigned to Falko.

I will get back to this issue asap

Add
"Sentence case."
"Title Case"
"tOGGLE cASE"
to the "Format - Case/Characters" menu.

Considered for 'Office Later'.

reassigning & adding keywords according to new RFE process - sophie

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.

*** Issue 48720 has been marked as a duplicate of this issue. ***

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 )

Not to forget a right-click context menu entry too! Probably the most widely
used means of case-change!

*** Issue 60702 has been marked as a duplicate of this issue. ***

Corrected spelling in Summary.
Would suggest (to the owner) changing summary to avoid duplicates:
"Provide: Toggle case, First Letter Capitalized and Sentence case"

Regards,
Andrew

*** Issue 61339 has been marked as a duplicate of this issue. ***

*** Issue 54632 has been marked as a duplicate of this issue. ***

*** Issue 30132 has been marked as a duplicate of this issue. ***

*** Issue 24780 has been marked as a duplicate of this issue. ***

*** Issue 41457 has been marked as a duplicate of this issue. ***

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.

Regards,
Andrew


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. 

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

(2)
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 
case)
Format -> Case/Character -> Small Capitals ( Menu option also written in small 
capitals)
Format -> Case/Character -> Sentence case (New feature, First character of 
sentence capital, rest characters small, Menu option also written in sentence 
case)
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.
...............................................................................

Note: Toggling Case by pressing Shift+F3, is covered by Issue 12454.

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. 

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?

I have posted in issue http://qa.openoffice.org/issues/show_bug.cgi?id=66344 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:
 SENTENCE: CASE_UPPER
 WORD_BEGIN: CASE_UPPER
 WORD_INSIDE: CASE_LOWER
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.

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

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

*** Issue 66910 has been marked as a duplicate of this issue. ***

Beyond:
  SENTENCE_START
  WORD_START and
  WORD_INSIDE

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

Yes, I want to get this feature. But why nobody fixed this? I want to try and
give OOo a patch.

*** Issue 23864 has been marked as a duplicate of this issue. ***

*** Issue 54867 has been marked as a duplicate of this issue. ***

*** Issue 57973 has been marked as a duplicate of this issue. ***

*** Issue 65860 has been marked as a duplicate of this issue. ***

adjusted summary to catch title case

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?

A poster above had the solution written but didn't know how to submit the patch
to the OpenOffice team.

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. 

*** Issue 75218 has been marked as a duplicate of this issue. ***

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.

*** Issue 77794 has been marked as a duplicate of this issue. ***

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.

*** Issue 82642 has been marked as a duplicate of this issue. ***

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.  

Set target to 3.x.

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. 

Very useful feature, please don't wait too much to add it 

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.

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. 

adding pepp to issue.

Pepp has created a patch to add this feature.  Attaching now.

Created attachment 61070 [details]
artwork

Created attachment 61071 [details]
Artwork

Created attachment 61072 [details]
new source file to add in 'i18npool/source/transliteration/'

Created attachment 61073 [details]
svn diff output

Dispatching issue to hopefully suitable dev owner.

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

I'm working on adapting the patch to include mod's comments/remarks

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 = "com.sun.star.i18n.Transliteration.sentencecase";

which should be 

    implementationName = "com.sun.star.i18n.Transliteration.SENTENCE_CASE";

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
implementation?


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


For better readability I suggest to rename class sentencecase to
Transliteration_sentencecase, and in
i18npool/source/registerservices/registerservices.cxx
change
IMPL_CREATEINSTANCE( sentencecase )
to
IMPL_CREATEINSTANCE( Transliteration_sentencecase )
and thus

{   TRLT_SERVICELNAME_L10N,
    TRLT_IMPLNAME_PREFIX  "SENTENCE_CASE",
    &sentencecase_CreateInstance },

to

{   TRLT_SERVICELNAME_L10N,
    TRLT_IMPLNAME_PREFIX  "SENTENCE_CASE",
    &Transliteration_sentencecase_CreateInstance },


There's no need for
#define	TRLT_SERVICELNAME_SENTENCECASE	TRLT_SERVICELNAME_PREFIX "sentencecase"
in i18npool/inc/servicename.hxx


TRANSLITERATION_ONETOONE( sentencecase )
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
com.sun.star.i18n.KCharacterType 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.


Performance:

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


SwEditShell::TransliterateText()
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
binfilter.


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

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.

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.

Created attachment 61157 [details]
updated patch

Created attachment 61159 [details]
new source file containing sentence_case transliterator

Created attachment 61160 [details]
new header file containing sentence_case transliterator

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

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.

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.

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.

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

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

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.

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.

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)

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

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.

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!

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

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/makefile.mk
Adding         i18npool/source/transliteration/transliteration_sentencecase.cxx
Adding         offapi/com/sun/star/i18n/TransliterationModulesExtra.idl
Sending        offapi/com/sun/star/i18n/makefile.mk
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

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?

Created attachment 62635 [details]
Minor patch to left the uppercase letters unchanged

tl->pepp: patch applied. Works fine now. Thanks!

Created attachment 62862 [details]
pepp->tl : ui changes listing

tl->clu: Can you have a look at the latest attachment and see if you have
anything you need to write a small spec?

TL->FL: As discussed, please take over for review/approval of UI changes.

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?

"First Letter Capitalized"/"capitalize first letter" is already supported by OOo.
See Format - Character - Pane Font Effects - list box Effects - entry Title.

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.

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.

TL->FL: We need to meet in order to create the required spec since the feature
set to implement is clear now.

Ok, starting over in CWS tl74 now...

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

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 

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?

.

Can you stop sending me this annoying messages!?


               Ponny

Ok, I was told the new menu entries should read like this:
  - Sentence case
  - lowercase
  - UPPERCASE
  - Capitalize Every Word
  - tOGGLE cASE

Fixed in CWS tl74.

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 askoxford.com's 
faqs, but it would be a nice option to have.

Link to spec added.

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.

Verified in CWS tl74.
Find test case here:
http://quaste.services.openoffice.org/index.php?option=com_tcs&task=tcs_show&tcsid=3116

Verified in DEV300m83 with TCS - closing - Sophie

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
(http://www.openoffice.org/issues/show_bug.cgi?id=113558), 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.

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.