LO 3.5 - Can't see page margins in Writer

Hi :slight_smile:
No worries.  We often argue and disagree with each other.  It's amazing the things that people get passionate about!  At least this one is relevant and on-topic!

It's worth posting a feature-request.  As you point out it surely isn't too tough although it's a bit of a mystery why it isn't already being given as one.  Just post a bug-report and use the drop-downs to make it a feature-request.  This guide might help
http://wiki.documentfoundation.org/BugReport

In the mean-time it's well worth trying Regina's advice. 
Good luck and regards from
Tom :slight_smile:

...

Frankly, I view the elimination of visible margins as part of the dumbing
down of user interfaces that I'm seeing in Mac OS Lion, Ubuntu 11.10, and
now LO. It's the "let's make it pretty to look at even if if compromises
the usefulness" school of thought. Clearly, LO Writer is not as pretty to
look at with margin guides showing. But, for me, it's more useful.
C'mon--this is a "View" menu option if there ever was one.

...

From what I gather, it was/is based on a Microsoft Word & OpenOffice 'me

too' design:

<http://wiki.documentfoundation.org/Design/Whiteboard/Writer_SpecialIndicators#Document_Margin_Design>
[Document Margin Design]
--> <http://wiki.services.openoffice.org/wiki/DocumentBorder>

Maybe also of interest:
<http://listarchives.libreoffice.org/global/design/msg03155.html>
[libreoffice-design] [Info] Whiteboard page for Special Indicators in
Writer (Header / Footer, Document Border, Page Break)
<http://wiki.documentfoundation.org/Design/Whiteboards/DocumentBackground>
<http://www.digipedia.pl/usenet/thread/11689/3242/>
[Some ideas to improve the look & feel of LO]
<http://www.mail-archive.com/design@global.libreoffice.org/msg03279.html>
[same thread - different format]
<http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-July/000078.html>
[Libreoffice-ux-advise] Header and Footers separators design
(looks to be the initial start of the change)

Unanswered request on the Design list:
<http://listarchives.libreoffice.org/global/design/msg03578.html>
[libreoffice-design] Text boundaries like 3.4.x

I tried searching for a bug report about the change but couldn't find
one. I'm surprised that a change like this doesn't have one. The only
thing I could find is:
<https://bugs.freedesktop.org/show_bug.cgi?id=31251>
[Bug 31251 - [EasyHack] Make the default page look better ]
But that seems to be only related to the entire page background/shadow.

FWIW: I agree that this is a regression & that a user option to turn the
margin lines on/off should be added. I'd recommend filing a bug report
so that the issue gets documented & into the report system.

Gary

I can only tell you where it was:
Tools - Options...
  +OpenOffice.org - Appearance
    Text Boundaries (2nd from the top)

Perhaps they just have it off by default? Seems silly to re-program
just for a tick box setting.

Regina ,

True for "page" layouts, but simple try a multiple column layout and try to position a picture (anchored to the page)
The column boundaries are also gone.

Greetz

Fernand

I can only tell you where it was:
Tools - Options...
  +OpenOffice.org - Appearance
    Text Boundaries (2nd from the top)

Perhaps they just have it off by default? Seems silly to re-program
just for a tick box setting.

Hi Fernand,

Fernand Vanrie schrieb:

Regina ,

True for "page" layouts, but simple try a multiple column layout and try
to position a picture (anchored to the page)
The column boundaries are also gone.

If you anchor a picture to page, then the reference is the page not a column. Anchoring to a page means, that the picture hovers over the continuous text and stays on that specific page regardless how the continuous text is changed. In such a situation an alignment to columns seems questionable to me. If you want your picture inside a column use anchoring to paragraph.

Besides that, you know the column width and can set width and position of the picture accordingly. I know that people like using the mouse, but using the dialog is much more precise and flexible.

Kind regards
Regina

Regina ,

You cut a few corners here, see my remarks inside

Hi Fernand,

Fernand Vanrie schrieb:

Regina ,

True for "page" layouts, but simple try a multiple column layout and try
to position a picture (anchored to the page)
The column boundaries are also gone.

If you anchor a picture to page, then the reference is the page not a column. Anchoring to a page means, that the picture hovers over the continuous text and stays on that specific page regardless how the continuous text is changed

When using a multiple column layout, in 95% of the cases the pictures are anchored to the page, because the editor want to fix the images on a specific place in his layout, and most pictures are wider than 1 column, see most of "magazines" layout.
We produce 8.000 magazine pages a year, using OO-LO, and yes we positioning the pictures using Macro's etc, but in the end the user want to move the images and then we surly need the colomn bouderies as a guide....

. In such a situation an alignment to columns seems questionable to me. If you want your picture inside a column use anchoring to paragraph.

Besides that, you know the column width and can set width and position of the picture accordingly.

When using a 4 column layout, its problematic to have al this postions in mind 9 mm, 43 mm , 95 mm, ect....

I know that people like using the mouse, but using the dialog is much more precise and flexible.

here i can 100% agree, but we are talking about 5% of the users who understand the allignment techniques, the rest use the mouse , eye and boundarie lines :slight_smile:

Another suggestion: Use F11 to open the Styles & Formating dialog.
Click the Page styles icon. The right click the Default page style.
Using the Border tab, Set All Four Borders. Then select the width and
color of the border. Click OK.
     This could also be done with a page style you want to use.
     Granted when printing, it does require opening the page style and
selecting Set No Borders in this tab.

--Dan

Dan ,

Thanks for the tip , page boundary's are a minnor problem , having no COLUMN boundaries can not been worked around

I just upgraded to 3.5 from 3.4.4. There are no page margins visible
for my
Writer documents last saved in 3.4.4. Am I missing something? I've
looked
for a preference and can't find one. I'm using Mac OS 10.7.3.

Thanks.

I think one of the new features in 3.5 is getting rid of the visible
”border” for the margins, if that's what you mean.

feature??? to eliminate a wanted behaviour is considered a feature??

Please feel free to replace that word with another word of your
choice. Maybe ”changes” would be better in this case:
”I think one of the changes in 3.5 is getting rid of…”

Or maybe not, hard for me to tell. English is not my native language,
but I do the best I can. It's good enough in most cases, but obviously
not always.

Kind regards

Johnny Rosenberg
ジョニー・ローゼンバーグ

No, this is not a case. Text Boundaries are still on by default, but instead
of lines around printing area, they are simply small lines in each corner of a
page. Turning Text Boundaries off will hide them.

At least in 3.5-rc3, because I had no time to test final 3.5.

Jean-Francois Nifenecker wrote:

What bothers me the more on the users lists (FR is the same for that
matter) is the recurring motto Regina sang: "discussing here will
not make it appear."

Hi Jean-Francois,

well, but it's true - *someone* would need to carry the discussion
to the relevant list, see below. I would be very surprised if this
is different in any other free software project of this size.

To tell the truth, this is a shoking answer. Users may not wish to
register to some "strange" or hidden list for a one-shot message,
non-english speaking users might feel they are set aside. As the
users lists are frequently visited by members of TDF, it would seem
important these knowledgeable people report to the devs, if the devs
themselves don't lurk round here (which is a shame
development-wise).

If you want the devs to actually work on code, instead of reading
emails all day (mind that, typically, the core developer list has
some 1000+ postings alone per month), it has to be like this.
Someone would need to mine for the bits of developer-relevant
information among sometimes rather general discussions, distill it
down to actionable content, and bring it to the right place -
ux-advise for the question at hand.

If you're really passionate about this topic, it could be you -
isn't it always better to be part of the solution, rather than part
of the problem? :wink:

Cheers,

-- Thorsten

Hi :slight_smile:
+1
Regina gives good advice even if it's not always what you want to hear.  In general i find that acting on Regina's advice gets the job done.

Almost everyone else gets side-tracked from time-to-time.  Some more than others.  Regina has been criticised quite a lot in the last few days and i think quite unfairly.  She is not paid to give advice and help people.  I don't think anyone here is. 
Regards from
Tom :slight_smile:

Hi Tom,

Regina gives good advice even if it's not always what you
want to hear. In general i find that acting on Regina's advice gets
the job done.

I don't question Regina's answers which I always appreciate. I question *this specific* answer I quoted before.

Almost everyone else gets side-tracked from time-to-time. Some more
than others. Regina has been criticised quite a lot in the last few
days and i think quite unfairly. She is not paid to give advice and
help people. I don't think anyone here is.

This is completely irrelevant to the topic and doesn't apply to me.

Hi Thorsten,

thanks for your answer.

well, but it's true - *someone* would need to carry the discussion
to the relevant list, see below. I would be very surprised if this
is different in any other free software project of this size.

Sure.

If you want the devs to actually work on code, instead of reading
emails all day (mind that, typically, the core developer list has
some 1000+ postings alone per month), it has to be like this.

I can understand that.

Someone would need to mine for the bits of developer-relevant
information among sometimes rather general discussions, distill it
down to actionable content, and bring it to the right place -
ux-advise for the question at hand.

The place where to bring questions to the devs has to be a visible and accessible place.

Visible: the us list is completely hidden (at least it was to me until Cedric brought it to my attention). From what I can see, it is also hidden to most of the public lists members.

Accessible: I know of plenty who don't speak or read English. Thus, even if they'd know about ux, they couldn't express themselves.

I guess there's some work to be done to resolve those two points.

BTW, what if many people jump in the ux list and post thousands of messages? :wink:

If you're really passionate about this topic, it could be you -

Well, I could do it, yes. In fact, as you might have seen, I did for the first time a few hours ago. I can say that the latest answer my message received is not that encouraging (in short: do it yourself. Doh).

isn't it always better to be part of the solution, rather than part
of the problem? :wink:

:slight_smile:

Thanks for your answer. All the best,

Final 3.5 is 3.5-rc3

Jean-Francois Nifenecker wrote:

The place where to bring questions to the devs has to be a visible
and accessible place.

[...]

I guess there's some work to be done to resolve those two points.

Hi Jean-Francois,

not necessarily - what would be equally workable is a group of
change agents (Regina, Cor, NoOp, you in this case, but also UX
people like Christoph), who have their eyes & ears here and at the
forums and convey to ux-advise or the dev list.

Also, what would greatly reduce the cost & friction that changes
will cause in the future, is early feedback. We invested quite some
resources into providing nightly builds here:

http://dev-builds.libreoffice.org/daily/

(and my, and other hackers' personal time and money to keep those
hosts running), so any suggestion to have people actually download &
play with those builds greatly appreciated.

Cedric blogged his feature here:

http://cedric.bosdonnat.free.fr/wordpress/?p=818

(that's also aggregated on planet.documentfoundation.org), but
possibly we could do better spreading the word - would someone
(you?) be interested in compiling a weekly or monthly newsletter for
LibreOffice?

BTW, what if many people jump in the ux list and post thousands of
messages? :wink:

Well, ux-advise has a rather narrow topic, that should naturally
reduce the breadth of the discussion - otherwise, more participation
is a problem I would love to have there. :wink:

Well, I could do it, yes. In fact, as you might have seen, I did for
the first time a few hours ago. I can say that the latest answer my
message received is not that encouraging (in short: do it yourself.
Doh).

Thanks for jumping in indeed - well, you *did* it yourself. Let's
see where that (constructive) discussion gets us to.

Cheers,

-- Thorsten

Hallo Thorsten ,

A agree, i also looked over the possible problems with no margins for a page, but there was no communication over the column margins. Like i sayed before there are workarounds for the page margins, but working with columns and pictures covering more than 1 column becomes very problematic (imposible)

Greetz

Fernand

Hi Fernand, hi all,

Fernand Vanrie schrieb:
[..]

When using a multiple column layout, in 95% of the cases the pictures
are anchored to the page, because the editor want to fix the images on a
specific place in his layout, and most pictures are wider than 1 column,
see most of "magazines" layout.
We produce 8.000 magazine pages a year, using OO-LO, and yes we
positioning the pictures using Macro's etc, but in the end the user want
to move the images and then we surly need the colomn bouderies as a
guide....

If I understand it right, the boundaries are only needed to align pictures with the mouse. If that is true, I think, a better solution would be not bringing back the border lines, but add a snapping feature. So that you can not only snap to grid (who uses that and to what purpose?) but snap to layout relevant positions, for example to paragraph border, indent position, page border, explicit tabs.

What do you think?

Kind regards
Regina

"What you see is what you get" is the rule of thumb.
It's an interface for human beings.
Anything else is asking for trouble.