Add option to preserve uppercase / force lowercase for title and sentence casing

[eltos]

I would like to request an option "force-lowercase" to control whether to keep uppercase letters or not in the titlecase and sentencecase functions. The main use case for this is acronyms and proper names in titles/headings, and also sentence continuation in ambiguous cases (see #39).

With force-lowercase: false (default) these two functions would only transform lowercase to uppercase letters as required, but not vice-verca (i.e. keep what is already uppercase). This is the current behaviour of the titlecase function.

With force-lowercase: true both functions would additionally transform uppercase letters to lowercase as per the styling rules, so as to fix ALL UPPERCASE INPUTS. This is the current behaviour of the sentencecase function.

Example (using typst):

#import "@preview/decasify:0.9.0": sentencecase, titlecase
#set text(lang: "en")

#sentencecase[Typst supports export to PDF and HTML.]
// Output: Typst supports export to PDF and HTML.

#titlecase[Typst supports export to PDF and HTML.] // current behaviour
// Output: Typst Supports Export to PDF and HTML.

#sentencecase(force-lowercase: true)[TYPST SUPPORTS EXPORT TO PDF AND HTML.] // current behaviour
// Output: Typst supports export to pdf and html.

#titlecase(force-lowercase: true)[TYPST SUPPORTS EXPORT TO PDF AND HTML.]
// Output: Typst Supports Export to Pdf and Html.

Note that in principle force-lowercase: true in the above example could then also be achieved with #sentencecase(lowercase[TYPST ...]) once the default behaviour has been altered to preserve uppercase letters

I would favour if the default setting was force-lowercase: false consistently for both titlecase and sentencecase, i.e. preserving the current behaviour of the titlecase function. Alternatively, force-lowercase: false could be the default for the titlecase function and force-lowercase: true the default for the sentencecase function to keep the respective current behaviour of either function as-is, while allowing to change it to the respective opposite behaviour if desired.
As a bonus, there could be a clever force-lowercase: auto as default for either function, which would translate to force-lowercase: true if more than 50% of characters in the input are already uppercase, and translate to force-lowercase: false otherwise.

[alerque]

@ertugruluyar-github Replying to your comments in this issue where they are actually on topic:

What if we enter all data as titlecase with acronyms like "Title Case with ACRONYM" and when converting to lower or sentence case, the words that already written uppercase excluded?

That might be a pragmatic way to handle content some use cases. The same logic would be useless for my primary use case—converting ALL CAPS DATA to properly title cased titles. The same problem could catch you if your data entry was anything but proper. As the most semantically rich format, titled cased content is the easiest to convert to other cases, but even that is not going to be 100%.

I'm willing to support some option for preserving all capped data in non-all cap strings as an optional behavior. Lets play around with that some and figure out what each language is going to need. For example is there a lower limit on the number of letters an ACRONYM should have?

Or when using this case funtions, if given a parameter called "excluded-words" to specify what we don't change the case?

I think this would be a useful feature for exceptions anyway, but probably just excluding them won't be as versatile as a list of target words an their desired cases. This should probably be it's own feature request, can you open this as a new issue please?

And this in this parameter's default values we can define some default values that language specific. And also, to give user flexibility, we can also give another parameter called "included" to give user to force some words affected by the function.

Please include this is your issue, and what you might expect the end user API to look like. Now we're talking about making a stateful converter or at least having some sort of config builder, and the ergonomics of this need to be considered.

[ertugruluyar-github]

I'm willing to support some option for preserving all capped data in non-all cap strings as an optional behavior. Lets play around with that some and figure out what each language is going to need. For example is there a lower limit on the number of letters an ACRONYM should have?

Thank you, I think lower limit of acronyms in Turkish is 2, meaning I didn't see one word acronym ever, at least two word. But I am working at university, so I can ask the research assistant of the Turkish Language Department.

[ertugruluyar-github]

I want to use this package only in the title and the other little things in my thesis template. Meaning, I'am not gonna let the user interact with this package on text that user write. To do so, I am gonna write a manager file like class. But I don't know what happen if the user add decasify package on top of mine?

For example in titles:

#import "/src/core/text-case-manager.typ": upper-case
show heading.where(level:1): set upper-case()

So, in my use case and most people's, the excluded and included words parameter will be enough. See #42