Dear Kevin,
the principles behind the Writer UI are WYSIWYG so including corner marks
could destroy this principle. Page borders depend on the printer driver
settings. If you use a printer driver that allows the use of 0" border then
you can use it. To check the driver's setting just open the "Page" tabpage
within the format page dialog and put your cursor into the page margins
spinboxes and use PgUp/PgDown to see the borders allowed by the printer
driver settings. If you really want such corner marks then it should be a
configurable setting of the "control character" mode that you can switch on
within the "Standard" function bar.
KG03 - I think the WYSIWYG paradigm is understood. Our page metaphor and
text alignment reinforces the conceptual frame. Do we need a boarder around
each line of text, so people don't get lost and know it's a line?
Furthermore, according to your argument, shouldn't the page boarder be
printed ;) Yes, there is a relationship to printing, but many people author
document with no intent of printing. Anyhoo, my goal is to reduce the
a word processing application in the first case _is_ for writing and for
printing documents like letters and books and the Writer application can
do a lot more than people are expecting. For example in Writer you can
work with connected floating frames like within a DTP program. People
need the page border lines to distinguish the area where you can input
text from the area where you include eg. fold marks. The UI
differentiates the grey (unprintable) area from the white background
(printable area). Within the printable area you have the document
boundaries for text input and the page border where you can just add
text (drawing) objects like fold marks. In the mean time I think that
we're talking a bit at cross-purposes but I still believe that the
current page boundary border is something that users still need.
Changing the UI representation of the border line might be something
where an experienced Writer developer can work on but it shouldn't be
switched-off by default. If such a change is implemented then it should
be configurable. And if the Novell founded go-oo.org application fork of
OpenOffice.org that is nowerdays re-founded as LO (or Meeks) thinks that
they want to change something for their users (I talk about enterprise
customers of Canonical, RedHat and Novell/SuSE) then I think there's no
duty to go the same way just because they want to do so. Apache
OpenOffice is the official successor of OpenOffice.org and download
numbers show the evidence that it's vibrant community is still
successfully working on this project and that people are satisfied.
Streamlining the UI to please the user base is something that is an
important step within the development of an application but you have to
carefully weight pros and cons.
visual weight of the UI and help people focus on the content. I'm looking
to apply this goal through the UI. A content-oriented, modern, light-weight
UI is what the community is asking for. Everything should be considered.
Please show me some evidence on your last assumption. Have you done UI
studies besides the wiki entry and representative surveys about this topic ?
It's important to check our assumptions, and ask why is something there.
Please be open to focusing on the design problem, versus the code history.
Your response explain what it is, not why it is. I'm trying to explore
different paths to realize my design goal. If you have any suggestions or
ideas on how to realize this goal within the page canvas, I'd love to hear
from you.
Kind regards, Joost
---------------------------------------------------------------------
To unsubscribe, e-mail: ooo-users-unsubscr...@incubator.apache.org
For additional commands, e-mail: ooo-users-h...@incubator.apache.org
