Desktop Publishing is Wrong

When I first started using computers a “word processor” was a program that edited text. The most common and affordable printers were dot-matrix and people who wanted good quality printing used daisy wheel printers. Text from a word processor was sent to a printer a letter at a time. The options for fancy printing were bold and italic (for dot-matrix), underlines, and the use of spaces to justify text.

It really wasn’t much good if you wanted to include pictures, graphs, or tables. But if you just wanted to write some text it worked really well.

When you were editing text it was typical that the entire screen (25 rows of 80 columns) would be filled with the text you were writing. Some word processors used 2 or 3 lines at the top or bottom of the screen to display status information.

Some time after that desktop publishing (DTP) programs became available. Initially most people had no interest in them because of the lack of suitable printers, the early LASER printers were very expensive and the graphics mode of dot matrix printers was slow to print and gave fairly low quality. Printing graphics on a cheap dot matrix printer using the thin continuous paper usually resulted in damaging the paper – a bad result that wasn’t worth the effort.

When LASER and Inkjet printers started to become common word processing programs started getting many more features and basically took over from desktop publishing programs. This made them slower and more cumbersome to use. For example Star Office/OpenOffice/LibreOffice has distinguished itself by remaining equally slow as it transitioned from running on an OS/2 system with 16M of RAM in the early 90’s to a Linux system with 256M of RAM in the late 90’s to a Linux system with 1G of RAM in more recent times. It’s nice that with the development of PCs that have AMD64 CPUs and 4G+ of RAM we have finally managed to increase PC power faster than LibreOffice can consume it. But it would be nicer if they could optimise for the common cases. LibreOffice isn’t the only culprit, it seems that every word processor that has been in continual development for that period of time has had the same feature bloat.

The DTP features that made word processing programs so much slower also required more menus to control them. So instead of just having text on the screen with maybe a couple of lines for status we have a menu bar at the top followed by a couple of lines of “toolbars”, then a line showing how much width of the screen is used for margins. At the bottom of the screen there’s a search bar and a status bar.

Screen Layout

By definition the operation of a DTP program will be based around the size of the paper to be used. The default for this is A4 (or “Letter” in the US) in a “portrait” layout (higher than it is wide). The cheapest (and therefore most common) monitors in use are designed for displaying wide-screen 16:9 ratio movies. So we have images of A4 paper with a width:height ratio of 0.707:1 displayed on a wide-screen monitor with a 1.777:1 ratio. This means that only about 40% of the screen space would be used if you don’t zoom in (but if you zoom in then you can’t see many rows of text on the screen). One of the stupid ways this is used is by companies that send around word processing documents when plain text files would do, so everyone who reads the document uses a small portion of the screen space and a large portion of the email bandwidth.

Note that this problem of wasted screen space isn’t specific to DTP programs. When I use the Google Keep website [1] to edit notes on my PC they take up a small fraction of the screen space (about 1/3 screen width and 80% screen height) for no good reason. Keep displays about 70 characters per line and 36 lines per page. Really every program that allows editing moderate amounts of text should allow more than 80 characters per line if the screen is large enough and as many lines as fit on the screen.

One way to alleviate the screen waste on DTP programs is to use a “landscape” layout for the paper. This is something that all modern printers support (AFAIK the only printers you can buy nowadays are LASER and ink-jet and it’s just a big image that gets sent to the printer). I tried to do this with LibreOffice but couldn’t figure out how. I’m sure that someone will comment and tell me I’m stupid for missing it, but I think that when someone with my experience of computers can’t easily figure out how to perform what should be a simple task then it’s unreasonably difficult for the vast majority of computer users who just want to print a document.

When trying to work out how to use landscape layout in LibreOffice I discovered the “Web Layout” option in the “View” menu which allows all the screen space to be used for text (apart from the menu bar, tool bars, etc). That also means that there are no page breaks! That means I can use LibreOffice to just write text, take advantage of the spelling and grammar correcting features, and only have screen space wasted by the tool bars and menus etc.

I never worked out how to get Google Docs to use a landscape document or a single webpage view. That’s especially disappointing given that the proportion of documents that are printed from Google Docs is probably much lower than most word processing or DTP programs.

What I Want

What I’d like to have is a word processing program that’s suitable for writing draft blog posts and magazine articles. For blog posts most of the formatting is done by the blog software and for magazine articles the editorial policy demands plain text in most situations, so there’s no possible benefit of DTP features.

The ability to edit a document on an Android phone and on a Linux PC is a good feature. While the size of a phone screen limits what can be done it does allow jotting down ideas and correcting mistakes. I previously wrote about using Google Keep on a phone for lecture notes [2]. It seems that the practical ability of Keep to edit notes on a PC is about limited to the notes for a 45 minute lecture. So while Keep works well for that task it won’t do well for anything bigger unless Google make some changes.

Google Docs is quite good for editing medium size documents on a phone if you use the Android app. Given the limitations of the device size and input capabilities it works really well. But it’s not much good for use on a PC.

I’ve seen a positive review of One Note from Microsoft [3]. But apart from the fact that it’s from Microsoft (with all the issues that involves) there’s the issue of requiring another account. Using an Android phone requires a Gmail account (in practice for almost all possible uses if not in theory) so there’s no need to get an extra account for Google Keep or Docs.

What would be ideal is an Android editor that could talk to a cloud service that I run (maybe using WebDAV) and which could use the same data as a Linux-X11 application.

Any suggestions?

10 comments to Desktop Publishing is Wrong

  • I agree that LibreOffice can be really slow. It’s outright painfully slow even on modern hardware if you have a large spreadsheet with lots of formulas.

    That said, to set landscape orientation in LO/OOo Writer (IMO) is fairly intuitively placed (unless they have moved it around since 3.5). It’s in Format -> Page -> Page (tab) -> Orientation (under “Paper format”), set to Portrait or Landscape as per your preference. The paper size is set in the same place. I think it’s the same way for all document types.

    The hard part is if you want to have different page orientations for different pages in the same document.

  • Michael: LibreOffice isn’t really slow any more. The first time I saw it perform reasonably was on an EeePC 701 after I had upgraded the RAM. The combination of a SSD (which performed well for reading even though writing was very slow) and a reasonable amount of RAM made it load faster than on a desktop PC of that era.

    I think that the intuitive place for the portrait/landscape menu option would be next to the one for “Web Layout”.

  • auser

    I disagree about lines longer then 80 chars. I dont like e.g. webpages that render text from one edge of the screen to the other. I find that i oftenhave to re-read as iloose the correct hight.
    Some googling yields which seems to agree…

  • henning

    “Web Layout” is in the “View”-menu, but portrait/landscape isn’t a property of how you view the document, but of how the document actually is laid out. So I don’t think they have much in common.

  • David Schmitt

    I often enjoy your posts for being thoughful and well researched. This one is missing an important point: for many, reading long lines – especially in a small font – is very hard to do. Reducing the line length leads to easier reading, this is why news papers have tiny columns and books are generally in portrait and not landscape format.

  • neonsignal

    My thinking is that word processors are complete overkill for most situations, adding complexity, inefficiency, and messy binary formats. In the odd case of needing to control layout, we should be using publishing software. Word processors are the middle option that doesn’t do anything well, whether as a note taker, or as a layout tool. It is only an historical accident that they came to dominate.
    Incidentally, MS Office used to put the page format controls under the File menu, which was even less intuitive than having it under a Format menu as OpenOffice does.

  • camh

    You can have Google docs show a web layout by changing the “edit” part in the URL to “pub”. You cannot edit in mode, but I prefer to use it to share docs to people in read-only mode.

  • One suggestion would be to just leave word processors and move to a lightweight markup language such as Markdown or (my favourite) reStructuredText: you can write it anywhere, with any setting you want (e.g. wide text lines) and then convert to the target format required, such as html snippets for blog articles, or doc/rtf for traditional publishers.

    Charlie Stross wrote a couple of articles on why this is a good solution, and they are an interesting read:

    One nice editor for both languages (under Linux and other desktop OSs) is retext, which is not exactly WYSIWYG, but has a realtime preview with the results, and GUI commands for the final conversion; alternatively you can just use any text editor you are confortable with.

  • auser: Thanks for that link, I probably should tweak my blog layout to display fewer characters per line.

    auser and David: In terms of editors I think that they should ALLOW longer lines, not require them. Currently popular editors such as Google Keep force people to use shorter lines regardless of what they want.

    henning: The “Web Layout” removes page breaks and line length limits. That seems like more of a property of how the document is laid out than portrait/landscape to me.

    neonsignal: I agree.

    camh: Thanks for that info. But editing is the main thing for me in this instance.

    Elena: Thanks for those links, after reading the latter one Restructured Text sounds good and that made me think of MediaWiki markup. It seems to me that if I had an Android app that would support logging in to a MediaWiki server and doing offline editing then I could do all the text editing I want and have version control on my MediaWiki server.

    Does anyone know of such an Android app? A quick Google search didn’t turn up anything.

  • Here in Germany Calligra-Office if featured regularly in the press, the package-description says, it has some DTP-capabilities, but it is supposed to be much more lightweight that libreoffice:

    andrew@s5:~$ aptitude show calligrawords
    Package: calligrawords
    State: not installed
    Version: 1:2.7.5-1+b7
    Priority: optional
    Section: text
    Maintainer: Debian Qt/KDE Maintainers
    Architecture: amd64
    Uncompressed Size: 6,775 k
    Depends: calligra-libs (= 1:2.7.5-1+b7), kde-runtime (> 4:4.10), libc6 (>=
    2.14), libgcc1 (>= 1:4.1.1), libkdecore5 (>= 4:4.4.0), libkdeui5 (>=
    4:4.4.0), libkparts4 (>= 4:4.5.85), libqt4-svg (>= 4:4.5.3), libqt4-xml
    (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>=
    4:4.7.0~beta1), libstdc++6 (>= 4.9), libwpd-0.9-9, libwpg-0.2-2,
    libwps-0.2-2, zlib1g (>= 1:1.1.4), calligrawords-data (>= 1:2.7.5-1)
    Suggests: khelpcenter4
    Breaks: kword (< 1:2.4)
    Replaces: kword (< 1:2.4)
    Description: word processor for the Calligra Suite
    Words is a FrameMaker-like word processing and desktop publishing application.
    It is capable of creating polished and professional looking documents. It can
    be used for desktop publishing, but also for "normal" word processing, like
    writing letters, reports and so on.

    This package is part of the Calligra Suite.

    Tags: uitoolkit::qt