Blank Cells Don't Change Font Size After Resizing Font?

This seems like new behavior in or one of the more recent releases:

  1. Create a blank calc spreadsheet, fill a few cells with some random text. The new text will be in the default font:

  2. Select all cells using Crtl-A, by clicking in the box in the corner of the row/column headers, etc.

  3. Increase the font size using format bar, Format->Cells, etc:image

  4. Only the cells with text in them are resized, blank cells retain the default font size:

I seem to remember that not long ago the behavior was that resizing fonts for “all” cells used to change the default font size for empty cells as well.

Am I mistaken? If this has been Calc’s behavior all along then I’m OK with this, I can just change the default font for new cells some other way.

1 Like

Neither with my current V7.5.3.2 not with the /.6.0.0.beta1 I can confirm such behaviour.

All selected cells accept the newly set font size whether they have content or not.

Such very strange experiences can be caused by user profile corruption. did you already test in safe mode?

See correction below.

Yes, same behavior in safe mode. I have installed from the Fedora repos:

Version: (X86_64)
Build ID: 50(Build:2)
CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

No clue then. Why should have a bug neither found in nor in
Concerning possible special problems with Fedora (or any Linux) I can’t help. But I also can’t imagine a reason in this case for a different behaviour.

See correction below.

I can reproduce the issue. However, I would never format a spreadsheet like that.
Hit F11, right-click cell style “Default” and change formatting attributes. Then remove any hard formatting (Ctrl+M).


Sorry. There must have been a mistake with my previous testing.
Repeating the test I also get the issue under Win 10.

Clue: This seems to be a bug introduced with V7.4 when the maximum number of columns was increased (from 2^10 to 2^14) . My portable V7.3.6 doesn’t show it.

With V7.5.3.2: If just the last column (XFD; number 16384) is excluded from the selection after Ctrl+A, or one of its cells is not blank, the changed cell attribute is applied as expected also to blank cells.

@wsanders1 please submit a bug.

I think that it’s a new feature (maybe to avoid CPU or RAM usage).

In my screenshot below, initially only B2 and C4 has text.
After Select All, and changing font size, only the cell range (B2:C4) between those corner cells get the formatting.

So if you need to format a range of cells, make sure that at least one cell in the boundary rows and columns has a value.

Tested with and

1 Like

Did you find any information to that effect anywhere?
New features should be announced in the Release Notes, e.g.

I can’t find out the bug report, I think this was a modification to avoid having the whole sheet with direct format, inadvertently, so only up to the last cell with data it’s modified.
It increases the file size, making slower save/open, Calc doesn’t like too much the whole sheet with direct format.

1 Like

Yep, I agree completely. This would be the best way.

Another workaround you can do is:

  • Select a column (or a few columns).
  • Choose your Fonts/Font Size.


  • Select a row (or a few rows).
  • Choose your Fonts/Font Size.

That will still work similar to what @wsanders1 was trying to accomplish, just with a few more clicks. :slight_smile:

This applies formatting to entire rows/columns at a time.

Side Note: Why does this work, but not the Ctrl+A “Highlight Everything” + apply fonts/font-sizes? See some of my discussion below. :slight_smile:

Yes, I suspect so too.

Probably around the time:

This allowed Calc to go from:

  • 1024 → 16k max columns
  • + ~1 million rows.

That unearthed a ton more previously-hidden performance problems, so many optimizations were implemented.

For example, before, LibreOffice Calc used to save:

  • Formatting PER CELL.

Now, Calc can save:

  • Formatting PER ROW/COLUMN.

With a few thousand rows/columns, that previous method “worked” and “ran okay”, but your document would be full of:

  • A1 = 12pt font
  • A2 = 12pt font
  • […]
  • A1024 = 12pt font

but once LO enabled millions of cells—it brought all CPUs to a complete crawl. Especially when many people would do like the OP:

  • Ctrl+A + Formatting

applying Direct Formatting onto millions of individual cells… but then only type actual info into a handful.

Now, using that row/column method mentioned above, Calc will save formatting similar to:

  • “Make Column A = 12pt font”

Now, instead of:

  • millions of completely blank cells all saying “make it this font size!”

Calc now condenses all that formatting down to 1! :slight_smile:

Side Note: Luboš Luňák implemented this feature in ~2022 + did tons of Calc optimizations. He even gave a talk at Collabora’s conference last year:

If you want all the juicy technical details, I also linked to a lot of the exact Calc bugs in my comment a few months ago:


I claimed there was a bug and @erAck suggested (to a different user) such a report should be filed.
Nobody did, seemingly, and I won’t. I have >30 open bugs, and this one isn’t important for me. Anyway I would reject any guess the change was intentional. Also mass-occurring direct cell formatting is handled efficiently by Cal (and .odf storage).
In addition: After Ctrl+A and de-selection of a single cell (A1 e.g.) the complete sheet (except A1) accepts the font attribute.

1 Like

In version in Win.10, it is also formatting empty cells.

Version: (x86) / LibreOffice Community
Build ID: 41d6f628ba3f046f16b5fa9fa8db8d4c2ab3b582
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: es-MX (es_MX); UI: en-US
Calc: threaded


Jumbo Sheets is still something different, with 16 million rows, and it’s not default but experimental. 1M rows are supported for years already. The switch from 1k columns to 16k columns was made.

Not true, if talking about file format. Calc was always able to save formatting per column/row. The article talks about in memory representation, where formatting runs per column (over rows) was always implemented, but with increasing columns to 16k a different approach to individual columns had to be taken (and that’s not only about formatting).

That was always exactly one formatting run within a column, not 1024 individual cell attributions.
The conclusion about Ctrl+A resulting in millions of individual formattings thus does not hold.


Thanks for those clarifications, @erAck.

It’s been quite a while since I read those linked posts/talks, so probably need a refresher myself through all those ol’ bug reports + blog posts with fresh eyes! :slight_smile:

It seems to be about the same behavior: tdf#156826.