Hey Telesto, on Mac, page break will be command + enter.

I am not able to replicate this bug on 
Version: 25.8.3.2 (AARCH64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 11; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

When I click on command+enter, I am taken to a new page. Could you please try to see if you're able to replicate this on the newest version? Does this happen for you on the Light theme as well?

Created attachment 204298 [details]
Screenshot

It's not about the page break being present. It is. It's about the visibility of the page break line itself. There is a lack of contrast, IMHO

Hi Telesto, after reviewing this, I am understanding now, and I am able to reproduce this on: 
Version: 25.8.3.2 (AARCH64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 11; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Thank you for reporting this bug.

Do you have a proposal? Tools > Options > Appearance: Customization > Page and column break. To me, the color is well balanced between "hard to see" and obtrusive.

(In reply to Heiko Tietze from comment #4)
> Do you have a proposal? Tools > Options > Appearance: Customization > Page
> and column break. To me, the color is well balanced between "hard to see"
> and obtrusive.

Not quite sure if the color as such being the problem. Might be the rendering of the dashed page break itself. The dashed break line looks like rectangle low resolution raster image with a dash inside (everything smeared/blurry) Especially noticeable in light mode . It doesn't scale either when zooming in/out.

Might be Mac specific or related to HiDPI

---

I didn't think of Tools > Options > Appearance: Customization.

I modified the color to red for multiple types of page breaks (page break, manual page break, automatic. It doesn't apply without or with restart of LibreOffice.
No difference after profile reset. Appears something being broke here too.


Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d20f7e9b86f2efa258db3e8456dd24d94190e0c5
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

(In reply to Telesto from comment #5)
> I modified the color to red...
> No difference after profile reset. Appears something being broke here too.
Works for me also on macOS even with [ ] Enable application theming off.

However, I see the dashed line iterating between the chosen color and white (in light mode it also has a white halo). Making this transparent leads to sharper dashes but wont make the line stand more out. 

IOW: we should investigate how dashed lines are drawn and ensure iterating between the defined color and transparent. If necessary I could imagine the width of the line stroke depending on high resolution.

White halo is indeed better description. It depends on zoom-level. It increases when zooming out (say zoom level 80%)

It looks the same as in master with
Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

It looks more crisp too me with
Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

FWIW: I don't think this being skia related

Hmm. With a default LO from master I get bright blue page break dashes, while I see that the ones in the screenshot are almost gray. It sure does make them harder to see in dark mode.

The colors for this stuff don't change with the theme (AFAICT) but the "Automatic" option in the settings UI just means "default", which is hardcoded. In our case, page breaks are hardcoded to blue.

@Telesto, did you modify the page break color in the settings/Preferences UI at all?

Actually, I think it *is* related to Skia rendering. I'm testing with:

Version: 25.8.2.2 (AARCH64)
Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f
CPU threads: 8; OS: macOS 26.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Skia rendering is decidedly less contrast-y than without (see attached picture). Skia HW vs. SW doesn't seem to make a difference.

Created attachment 204675 [details]
Page break rendering screenshot

Telesto's page break is much closer to Skia; differences might just be image compression. In any case, non-Skia rendering is a lot more contrasty.

(In reply to dcbw@libreoffice.org from comment #10)
> The colors for this stuff don't change with the theme...
It does, see svtools/source/config/colorcfg.cxx #546: COL_BLUE vs. 0x729FCF; done in https://gerrit.libreoffice.org/c/core/+/149059.

(In reply to Heiko Tietze from comment #13)
> (In reply to dcbw@libreoffice.org from comment #10)
> > The colors for this stuff don't change with the theme...
> It does, see svtools/source/config/colorcfg.cxx #546: COL_BLUE vs. 0x729FCF;
> done in https://gerrit.libreoffice.org/c/core/+/149059.

Ah, my bad, didn't read the code well enough. 

But somehow it doesn't actually change colors (when set to Automatic) because I can quit, change light/dark mode, relaunch, and the colors don't change. Darker parts are #000080 and light parts are #a0a0ff. This is with Skia disabled.

I can try to track this down if you'd like?

Also something odd: the GetHighContrastMode() branch here tries to pick another color, but then doesn't actually use it?

    std::vector<double> aStrokePattern;
    basegfx::BColor aColor = (SwViewOption::GetCurrentViewOptions().*m_pColorFn)().getBColor();
    if (rSettings.GetHighContrastMode())
    {
        // Only a solid line in high contrast mode
        aColor = rSettings.GetDialogTextColor().getBColor();
<---- aColor never referenced again... ---->
    }
    else
    {
        // Get a color for the contrast
        basegfx::BColor aHslLine = basegfx::utils::rgb2hsl(aColor);
        double nLuminance = aHslLine.getZ();
        nLuminance += (1.0 - nLuminance) * 0.75;
        if (aHslLine.getZ() > 0.7)
            nLuminance = aHslLine.getZ() * 0.7;
        aHslLine.setZ(nLuminance);
        const basegfx::BColor aOtherColor = basegfx::utils::hsl2rgb(aHslLine);

        // Compute the plain line
        aSeq.push_back(new drawinglayer::primitive2d::PolygonHairlinePrimitive2D(aPolygon, aOtherColor));

        // Dashed line in twips
        aStrokePattern.push_back(3);
        aStrokePattern.push_back(3);
    }

    // Compute the dashed line primitive
    aSeq.push_back(
            new drawinglayer::primitive2d::PolyPolygonStrokePrimitive2D(
                basegfx::B2DPolyPolygon(aPolygon),

-----> kinda feels like this should be aColor instead of *m_pColorFn)().getBColor()? Otherwise the GetHighContrastMode() branch is pointless...

                drawinglayer::attribute::LineAttribute((SwViewOption::GetCurrentViewOptions().*m_pColorFn)().getBColor()),
                drawinglayer::attribute::StrokeAttribute(std::move(aStrokePattern))));

    pProcessor->process(aSeq);

(In reply to dcbw@libreoffice.org from comment #10)
> @Telesto, did you modify the page break color in the settings/Preferences UI
> at all?

Ouch ... I made a mistake. I didn't change: "Page and column breaks" entry. So it's actually working..

I did change Page break; Manual page break; Automatic page break entry's. However those belong are spreadsheet settings, in hindsight

The old appearance dialog had clear nice grouped category's.

(In reply to dcbw@libreoffice.org from comment #12)
> Created attachment 204675 [details]
> Page break rendering screenshot
> 
> Telesto's page break is much closer to Skia; differences might just be image
> compression. In any case, non-Skia rendering is a lot more contrasty.

I tested it again. non-Skia rendering is indeed lot more contrasty - as in your screenshot - using

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ad5cb7e99f574c17811ef7d5419b35a95ed82696
CPU threads: 8; OS: macOS 14.7.4; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded