Add Increase and Decrease Font Size Shortcuts

[oooforum]

Fix for issue #54923
Ctrl + > to increase
Ctrl + < to decrese

[cbmarcum]

I just built this PR with trunk pulled in.
For me, the increase works but the decrease doesn't. I'm using an en-US keyboard layout and the key combination I'm using is CTRL Shift , (or CTRL <) and CTRL Shift . (or CTRL >).

[Pilot-Pirx]

Just for conformity with other office applications:
MS uses Ctrl-[ for decrease and Ctrl-] for increase.
LO uses the equivalent Ctrl-8 and Ctrl-9.

Setting these hotkeys by hand works for me, but the underlying function does not work as expected.
Increasing/decreasing jumps by 2...

[cbmarcum]

I think maybe this should discussed on dev@ to get some consensus on the key combination that would be appropriate because of the ramifications of this addition.

[leginee]

i have the case reviewed.

Why decrease specifically fails

On a US/UK keyboard, < is physically Shift+comma, so pressing "Ctrl+<" generates a key event of KEY_LESS + SHIFT + MOD1. But the PR binds decrease to LESS_MOD1 = KEY_LESS + MOD1 (no shift). The event carries SHIFT, the binding doesn't → no match → shrink never fires.

Increase works only by luck of the asymmetry: > is Shift+period, generating KEY_GREATER + SHIFT + MOD1, and the PR happens to bind it to GREATER_SHIFT_MOD1 — which does include SHIFT, so it matches.

So the same one-character inconsistency I flagged is precisely what users are reporting. The fix is LESS_MOD1 → LESS_SHIFT_MOD1. (This also explains why Pilot-Pirx said setting it by hand worked — he'd have entered a consistent combo.)

The separate "jumps by 2" complaint
That's not the binding — it's the command implementation. Writer's handler (txtattr.cxx:247-280) uses a hard-coded step:

const SwTwips lFontInc = 2 * 20; // +/- 2pt (txtattr.cxx:78)
const SwTwips lFontMaxSz = 72 * 20; // cap 72pt, floor 4pt
So .uno:Grow/.uno:Shrink change size by a flat ±2pt (4–72pt range), rather than stepping through the standard size list (8,9,10,11,12,14,16,18…) the way MS Word (Ctrl+[ / Ctrl+]) and LibreOffice (Ctrl+8 / Ctrl+9) do. That's long-standing AOO behavior, not something the PR introduced — and it's why Pilot-Pirx says it "does not work as expected."

Net verdict on PR #88

Binding bug (real, fixable): decrease broken by the missing SHIFT → change to LESS_SHIFT_MOD1.
Key-choice question (needs dev@): cbmarcum's point stands — Ctrl+[/] (MS) or Ctrl+8/9 (LO) would be more conformant and layout-robust than </>.
Behavior complaint (pre-existing, out of PR scope): the ±2pt step lives in the command, not the shortcut.