This doesn't look like an issue, but rather the regular behavior of any program. Please note that the page size and page orientation are independent things. For a brief explanation, please refer to http://athleticaid.com/yaquinapress/landscape.html (they refer to "page shape" as page size).

(In reply to Johnny_M from comment #1)
> This doesn't look like an issue, but rather the regular behavior of any
> program. Please note that the page size and page orientation are independent
> things. For a brief explanation, please refer to
> http://athleticaid.com/yaquinapress/landscape.html (they refer to "page
> shape" as page size).

I checked the mentioned link and found that all it says is just many other programs behave the same way. It does not say that this behaviour is the correct one. 

On the contrary, https://en.wikipedia.org/wiki/Page_orientation explicitly says that portrait is when the height is greater than the width:

> The [...] portrait [...] is [...] where the height of the display area is greater than the width [...]

So, I think following the _bad_ behaviour of other programs is not the good solution for LibreOffice. LO should behave nicely, logically and according to the expectations, rather than not following a behaviour that contradicts the expectations of most of the users. 

I liked when 15-20 years ago StarOffice moved the page formatting into the Format menu, rather than File menu, where MSWord and Google Docs still keep it. It simply is more logical and plausible under Format menu. Similarly, a vertical page should mean portrait, regardless what other programs say.

I reopen the ticket and please, re-consider changing the current behaviour. Thanks.

Sorry, I'm not on any LO team, so I shouldn't have closed. Setting the status back to unconfirmed.

(In reply to Johnny_M from comment #3)
> Sorry, I'm not on any LO team, so I shouldn't have closed. Setting the
> status back to unconfirmed.

Thanks, Johnny. 

I think the modification I asked in the bug starting message sounds to be simple. (The radiobutton should reflect the dimensions, when H>W then it should be Landscape and Portrait otherwise.)

I would categorise it as a low hanging fruit but one who knows the code may disagree with me. :)

I agree to Johnny, that everything is, how it should be, so I think, it is not a bug but a proposal for an enhancement (so I changed Importance to medium enhancement).

I agree to Johnny as well.
Closing as RESOLVED WONTFIX

I wanted to read again the explanation Johnny_M has linked but that page is not reachable any more (404 not found). I wanted to read it again, maybe I missed something the last time but I could not. Thus, I can read what I wrote in Comment #2. 

I still think that the current behaviour is very annoying, counter-intuitive and not understandable for most of the users therefore it should be changed.

So, would it be possible to reopen this bug as an improvement request, please?

I think my proposed idea would be totally clean, not confusing and easy to implement. The following steps should be done.
- the Width and Height fields should be kept as they are now
- the Orientation radio button should be replaced by a text that displays portrait/square/landscape if w<h, w=h, w>h, respectively
- there should be a "Swap Width and Height" button beside the two input fields.  

If somebody picks an item from the Format dropdown then the dimensions of the selected page should overwrite the existing W and H values according to this rule:
- The smaller dimension of the new page should overwrite the smaller value from W and H and the larger dimension of the new should overwrite the other one.

More precisely:

if (oldW > oldH) {  // was landscape
    W = max(newW, newH);
    H = min(newW, newH);
} else {   // was portrait or square
    W = min(newW, newH);
    H = max(newW, newH);
}

This logic would preserve the orientation of the page. 

...now I checked how this works in other programs I have installed. Well, GIMP uses a solution that is very similar to my proposal. Please, consider reopening it as an improvement proposal. Thanks.

Putting it back to unconfirmed for discussion...

(In reply to csongor from comment #7)
> I still think that the current behaviour is very annoying, counter-intuitive
> and not understandable for most of the users therefore it should be changed.

That's vastly exaggerated :-). At maximum it's a minor inconsistency.

> I think my proposed idea would be totally clean, not confusing and easy to
> implement. The following steps should be done.
> - the Width and Height fields should be kept as they are now
> - the Orientation radio button should be replaced by a text that displays
> portrait/square/landscape if w<h, w=h, w>h, respectively
> - there should be a "Swap Width and Height" button beside the two input
> fields.  

That complicates a simple interface way too much. What you ask for is an automatic adjustment of portrait or landscape depending on user settings. Would have the drawback of unintentional behavior in case you define landscape first and manipulate the values later.

I wonder if all this trouble is a language related thing. Would you still request the enhancement when the options have more generic terms and the function is called "flip"? (Not voting for this change, just as an example.)

Just to make it easier to understand what I want, I created a very basic implementation in JavaScript: https://codepen.io/halmai/pen/EbXwzz

(In reply to Heiko Tietze from comment #9)
> (In reply to csongor from comment #7)
> > I still think that the current behaviour is very annoying, counter-intuitive
> > and not understandable for most of the users therefore it should be changed.
> 
> That's vastly exaggerated :-). At maximum it's a minor inconsistency.

OK, I admit, I exaggerated it a bit. :) 


 
> > I think my proposed idea would be totally clean, not confusing and easy to
> > implement. The following steps should be done.
> > - the Width and Height fields should be kept as they are now
> > - the Orientation radio button should be replaced by a text that displays
> > portrait/square/landscape if w<h, w=h, w>h, respectively
> > - there should be a "Swap Width and Height" button beside the two input
> > fields.  
> 
> That complicates a simple interface way too much. What you ask for is an
> automatic adjustment of portrait or landscape depending on user settings.
> Would have the drawback of unintentional behavior in case you define
> landscape first and manipulate the values later.
> 
> I wonder if all this trouble is a language related thing. Would you still
> request the enhancement when the options have more generic terms and the
> function is called "flip"? (Not voting for this change, just as an example.)

Based on the basic JavaScript example I commented above, do you still think it is complicated?

I second the idea of a "swap/flip" button as opposed to trying to automatically change the values.

Also, the current behavior is definitely annoying. A use of of mine is to first pick a standard paper size, then divide the height by 3 or 4. This very often results in landscape dimensions in a portrait setting.

Unlike the case where you are setting the page to a known size (like 40x30 cm), I don't have all of these values memorized, so every time I have to remember one while I swap the values manually.

I think a swap button would satisfy the use cases that handled well by the current radio buttons, as well as the ones that aren't.

Correction to the above. I think a swap button is helpful regardless of whether or not the orientation is determined automatically.

(In reply to csongor from comment #7)
> I think my proposed idea would be totally clean, not confusing and easy to
> implement. The following steps should be done.
> - the Width and Height fields should be kept as they are now
> - the Orientation radio button should be replaced by a text that displays
> portrait/square/landscape if w<h, w=h, w>h, respectively
> - there should be a "Swap Width and Height" button beside the two input
> fields.  
I think this would be really an enhancement and I see no confusion to users as there is no additional user activity necessary in comparison with the current behavior.

The line "Orientation: () Portrait" in the page dialog should be changed to show only a string (portrait, square or landscape) that depends on the chosen width/height dimensions.

Instead of "() Landscape" there should be a swap button which exchanges width and height. Voilà.

Looking at the behavior now it is indeed flawed.

In sidebar: you can select a predefined size (A4, letter, ...) and change the orientation and all works fine. If you define your own custom size, then for no reason the change of orientation sets the size to 0, 0. 

In the dialog you have the same possibilities but here portrait and landscape is a radio button not a combo. The naming of labels is also different (Size vs. Format). If you set your custom size here and switch landscape/portrait then it just switches width/height regardless which is actually landscape and which portrait. 

Looking at this I find csongor@halmai.hu ideas a step in the right direction so we don't allow users to create inconsistencies with the UI. The severity of this is however in the low - "paper-cut" category.. 

Oh.. and the sidebar is different in writer and draw for no reason - including the label (again Size/Format).

We talked about this idea in the design meeting. The idea is accepted and might be easily implemented.

Switch the radio button from portrait to landscape when width becomes larger than height. If the user clicks the radio button it exchanges width/height. 

Regina, any concerns regarding ODF?

Patch submitted at https://gerrit.libreoffice.org/#/c/44876/

heiko tietze committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=637d96a25926e299fff5b4cf5a0055b1d171b23b

tdf#106890 Page orientation of User page size

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

verified in Versie: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU-threads: 4; Besturingssysteem: Linux 4.13; UI-render: standaard; VCL: gtk2; 
Locale: nl-NL (nl_NL.UTF-8); Calc: group

thanks csongor, Tomaž, Heiko!