LibreOffice 7.3.1.3 & 24.2.4.2 show the correct number, 142, of pages regardless of whether Show Whitespace is on or off.
Maybe you could make a bug report as suggested?
If I’m the guy to do it, sure. I’m not being lazy, but perhaps a more experienced hand would make a better report? Anyway nice to know that the bug is fairly recent.
I’m sorry, but if that is a bug. So what should be the difference between using the White Space option and not using it?
https://help.libreoffice.org/latest/en-US/text/swriter/01/show_whitespace.html
Well the page count shouldn’t change. As ajlittoz said, it’s just a convenience to give you a more compact view of your document.
And how can you condense the view without changing the pages? If you add more text to each page, the number of pages cannot remain the same.
Perhaps the only way would be to change the size of the pages, making them smaller.
But nothing is changed in the document, it’s simply a question of how it is presented on screen. You normally see an outline of the physical page including margins. With Whitespace off, you see only a fine line between pages and no margins.
You seem not to be familiar with the feature. It is only a display functionality. Vertical whitespace is suppressed on screen. Page break hints are kept. But page contents becomes faulty with page breaks becoming rather random: I saw a full page split into a series of “small pages” (in extreme cases, a “new” page containing only 3 lines). This split, without user action, is the bug.
BTW, speaking of page breaks, how come there’s no graphic to indicate that? I’m converting my footnotes (smaller font, as you suggest) and where I have a page break isn’t apparent except that the following paragraph has hatch marks in the Spotlight display. Oh, should I submit a bug report? Looks like this is well known anyway. But if you say so I’ll see if I can create a minimal example. But I suspect you will do a better job.
I can agree with that.
Sorry to break in on this, but I’m having the same problem in 26.2.0.3. With whitespace, my document is 563 pages, without it is variable, but I’ve seen as high as 984. You are right that suppressing whitespace is a convenience for the writer as it saves a lot of room and scrolling when editing. Also, when editing I sometimes have to re-check internal references, for instance if my text says to ‘see the chart on page whatever’, not having that chart on a page that can be counted upon is a great misfortune.
As for the double-space, I wonder why it is considered to be obsolete. It seems to me to be a smaller version of indenting paragraphs, that is, a help to the reader, and it just looks better. If it confuses modern document processors maybe that’s a thing, but, not being a coder, I can’t understand why it should.
Anyway, I would vote for fixing whatever it is that causes no-whitespace to be so hinkie.
Also, assuming that a document is destined for a digital publishing (such as Kindle) is there a way to create a linked footnote, to avoid the bottom-of-the-page physical location you mention in another comment?
ajlittoz has primed me on how to file a bug report. Let’s see if we can get any action on this. Some projects, the devs live in their own world and pay no attention to the mere users, other projects, user satisfaction is the whole show …
I have no idea why. The fact is this usage is no longer (very officially) recommended. And anyway it never adhered to typographical standards when these have a rule about post-punctuation spacing. Depending on country, this spacing is more or less wide and never equal two double-space. Don’t forget too that spaces are handled special when justification is enabled: the rendering engine can expand spaces to achieve justification. And this is where double spaces cause problems because they are not considered a a “single sequence” but each space is handled separately (and the result is not nice). As far as I understand Writer, devs have made absolutely no provision regarding double-spaces, hence the problem.
Double spaces could make sense in the mechanical typewriter era when you only had fixed constant pitch characters. But I have no certainty about it because usages were different in different countries (due to different typographical rules). Proportional fonts need more subtle tricks to request a change in space width. Unfortunately, the various spaces in the Unicode general punctuation block have not been assigned “expandable width” property and are taken with their raw font-defined width, which again won’t fit nicely in justification.
Last, HTML collapses all runs of spaces into a single space. To workaround this, I have seen a generator issuing a series of pairs space+nonbreaking space to fool browser rendering engines. But, once again, this is not ideal because the two categories of spaces have not the same base width.
I certainly agree that automatic justification can create unfortunate results, but they are not too bad, all-in-all. I have seen worse, in newspapers for instance, where the whole width of a column may be populated by a single word, such as ‘its’, spread out across the column. Maybe somebody ought to specify something or other as the standard. If they do, I vote for the double-space after periods.
I prefer it too, and so far I’m getting away with it. Yeah, there should be some option for a longer space perhaps. One should be able to format a doc as one damned well wants, no? I’m not going to get too worked up about it either way.
My idea about this issue, and more generally about punctuation in general, is to extend the AutoCorrect Options, Localized Options tab to be able to specify which type of space should automatically be added before or after some glyphs. This way, you could have a space taken from U+2001 to U+200A (chosen by user) followed by a typed ordinary space. Since the special spaces have not the “expandable” property, expansion is made on the ordinary space and we eliminate the problem with double spaces. You choose the width of the special space to fit your taste.
Some locales (e.g. French) already have provision for automatic insertion of non-breaking spaces (this is necessary to avoid separating the punctuation from its anchoring word with a line break). However, this is typographically wrong. NBSP is way too wide to comply with typography tradition. It comes from legacy character sets where the 190 count of printable characters did not allow for many spaces. Unfortunately, this was not revised with the advent of Unicode.
If I had the skill (and time too), I’d experiment along this idea.
Too much plumbing. It’s nice to have all that power, but sometimes, even tho I’m now a styling guy, I wish for my plain text editor where you get exactly what you type. Mind … I’ve now converted all my tables, and tho I’ve doubtless made many mistakes, it’s very cool to be able to, say, transpose an entire column or reformat the whole thing with a few commands.
BTW are my bug reports kosher?
It took me a while to find this ‘local options’ tab, but it looks promising, though, despite the open source nature of things, someone else such as LibreOffice will have to play with it. I am, as you say you are, unskilled in these things. I have enough trouble typing, much less coding enigmatic commands.
ajlittoz
February 18
GrumpyGeezer925:
Maybe somebody ought to specify something or other as the standard. If they do, I vote for the double-space after periods.
rayandrews:
Yeah, there should be some option for a longer space perhaps. One should be able to format a doc as one damned well wants, no?
My idea about this issue, and more generally about punctuation in general, is to extend the AutoCorrect Options, Localized Options tab to be able to specify which type of space should automatically be added before or after some glyphs. This way, you could have a space taken from U+2001 to U+200A (chosen by user) followed by a typed ordinary space. Since the special spaces have not the “expandable” property, expansion is made on the ordinary space and we eliminate the problem with double spaces. You choose the width of the special space to fit your taste.
Some locales (e.g. French) already have provision for automatic insertion of non-breaking spaces (this is necessary to avoid separating the punctuation from its anchoring word with a line break). However, this is typographically wrong. NBSP is way too wide to comply with typography tradition. It comes from legacy character sets where the 190 count of printable characters did not allow for many spaces. Unfortunately, this was not revised with the advent of Unicode.
If I had the skill (and time too), I’d experiment along this idea.
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
An update on this issue: made an exact clone of a 128 page doc, loaded it, LO in exactly the same state, and the page count was 27, this with the same display settings. Now, if I click on the ‘Page’ count, the ‘Go to Page’ will let me jump to an accurate page, like 127, but the counter still shows only 27 pages. So it’s clear that LO knows the accurate count, but isn’t displaying it. But if I go to the top of the doc, and then keep doing ‘Page Down’, you can see it ‘catching’ various page count mistakes and fixing them one by one until at the bottom of the doc, the count is correct.