Re: layout/screen units mess

From: Joaquín Cuenca Abela (
Date: Thu Aug 08 2002 - 18:12:40 EDT

  • Next message: Joaquín Cuenca Abela: "Re: Re: Commit: Docbook plugin work"

    On Thu, 2002-08-08 at 23:22, Dom Lachowicz wrote:
    > >> Also, I tend to lessen this requirement since a *lot* (read the
    > >> overwhelming majority) of users don't care about a single pixel
    > >> difference here and there in their word processing documents. It
    > >> simply
    > >> isn't a huge concern.
    > >
    > > That's because we don't have yet floating frames or stuff like that.
    > > Users get *angry* when they took hours to typeset a document, and then
    > > upgrade their wordprocessor and things renders differently.
    > AbiWord and Microsoft Word are not typesetting programs, and their use
    > as such should be strongly discouraged. Quark and FrameMaker are
    > typesetting programs. We do not want to put ourselves in the position
    > that KWord was so recently in - it didn't know whether to emulate
    > MSWord or FrameMaker. The results were horrendous.

    > IMO, you need to draw the distinction between a word processor's
    > requirements and a typesetting program's requirements. We are not a
    > pre-press application.
    > > I still have to find a user that don't cares about it. Of course, it
    > > exists a kind of users (the so called "professionals") that are not
    > > going to even take a look at AbiWord if they're not 100% sure that
    > > their
    > > documents are not going to be screwed.
    > You are defining "screwed" poorly here. The professionals that do care
    > that much should be using FrameMaker or even better, Lyx or LaTeX. The
    > professionals that I work with don't have these stringent of
    > requirements for the majority of their documents. For the ones that do
    > really matter that much, they choose the correct tool for the job.

    you're doing a:

    FrameMaker et al. keep layout
    word processors should not be used when you want to keep layout.

    And I don't agree with this reasoning. Word processors and FrameMaker
    have different user base, and usually very different UI, and they focus
    on different things. But I don't agree this one to be a fundamental
    difference, except by historical reasons

    > In Abi's case, layout will continue to look consistent on the user's
    > screen each time s/he loads the doc. It will look fine when printed. It
    > might not look exactly the same if he sends it to another user, but
    > then again, it might. Things might be a pixel off here and there.
    > Should we try to minimize this as much as possible? Yes, definitely.
    > Are we a pre-press application where each pixel off could cost us
    > thousands of dollars? Definitely not. I find this behavior to be
    > reasonable.

    just to make it crystal clear, I agree that sometimes it will be so hard
    to keep the same layout, that we will have to drop old code, put a big
    warning, and go for it.

    That don't means that it should be the norm.
    And if I use a three or four weird fonts that I downloaded somewhere 2
    years ago, I should be able to just give my doc to my friends to let
    them editing it.
    Embedding fonts is really an orthogonal issue to the typesetters/word
    processors discussions. Both of them should be able to do it.

    > >> I don't see this as a desired feature and only see it as causing an
    > >> unending sea of headaches for us as the project progresses. Yes, PDF
    > >> does do font subsetting to save size, and we wouldn't be able to do
    > >> that.
    > >
    > > we wouldn't be able to do that *entirely*. We can very well drop all
    > > the glyphs that don't belong to the document used languages (just
    > > removing CJK chars you're going to get a decent size).
    > And preclude the possibility of adding new information to the document
    > in a CJK language? Sounds like a sub-ideal solution to me.

    Yes, precluding the possibility of adding new information in a CJK
    language. Most probably we should have to give the option to the user
    (no embed, normal, full).

    But you can not say: "hey, docs are too big", "hey, I can not type in
    chinese", and "hey, the doc don't looks the same in my mate's computer".

    You can solve at most 2 of these problems. Not providing a font
    embedding options means that problem number 3 will not be solved. I for
    instance don't care the least about problem 2 (writing in chinese), but
    I want to solve 1 and 3 in my docs. Your preferences may be different,
    but I guess that most of people are going to have my preferences.

    > > And some people (me for instance) don't cares about a ~300k bloat if
    > > that means be able to see the document in any computer without having
    > > to
    > > worry downloading fonts.
    > A SVG, PNG, or PDF representation of the document might be more
    > appropriate if these are they types of situations you're looking to
    > avoid.

    And preventing last minute modifications? (that happen all the time)
    No thanks

    > >> I'm seeing a problem when we have a 10M glyph font embedded inside of
    > >> a
    > >> 1 page document. Do we want a 4MB, 1 page document? Is this the best
    > >> route to go? Can we be smart and say "you don't have fonts X, Y, Z. Go
    > >> get them from"?
    > >
    > > No, absolutely no. The user that receives your document may not have
    > > inet access (it happens a lot), or it may be expensive, or it may be a
    > > pain to download, or the site may be down, or...
    > This is exactly my point.

    ?? the document is easily reachable (usually in a CD or in a floppy).
    Fonts may not be downloadable, or be a pain to download all the need
    fonts. That's exactly the reverse of your point.

    > > and you want to print your end course document in the printer of your
    > > friend for *now*, or you're going to send abiword to the hell.
    > ABW->PDF->Printer if it really means that much to you.

    posterior modifications...

    > In *every* case
    > where my friends and I borrowed each other's printers, we weren't upset
    > if it looked a little different on their machine. This is at least
    > partially on dependent on the printer used (at least on Windows). I'm
    > arguing that the allowable margin of error here is greater than you'd
    > like to think. Think about it - I'm writing a paper on my machine.
    > There is a table in the document on page 1. Do I really care so much if
    > the table is 2cm or 2.1cm indented from the top when I move to a
    > friend's machine, or do I just care that the table is in the document?
    > What matters most tends to be WYSIWYG with regard to printer/screen
    > display. Most other stuff, in a word-processing world, tends to be a
    > distant second.

    That's the kind of stuff that puts a extra orphan line in the last page
    and that drives me mad... :)

    > >> Might Abi (read me, as a US citizen and the
    > >> project's maintainer) get sued because Abi now allows you to
    > >> redistribute (read circumvent) copyrighted material (this is a real
    > >> consideration under copyright law that we will have to be careful of,
    > >> not to mention the fscking DMCA).
    > >
    > > Of course, not.
    > Unlikely. This is not a risk I'm willing to take.

    Whatever. That's not more risky that buying eggs. And I'm willing to
    take the risk.

    > > We can not be more liable than, say, freetype. After all, a program to
    > > embed a font in a postscript file don't takes more than an afternoon to
    > > write, and nobody is going to sue gcc authors...
    > The *very* important distinction here is that freetype and gcc don't do
    > font embedding but AbiWord would. Sure, one can build a program using
    > freetype and gcc to embed a font inside of a PS file. What is that
    > program's name? Gee, it's AbiWord, pre-built for your circumvention and
    > embedding needs.

    Did I said something about respecting copyrights?

    Did I said something about the *TON* of programs already doing that
    (both commercials and free ones)?

    Even sending a font to the printer may be illegal, and ghostscript does
    it, for instance.

    When you buy a commercial program, they say you "don't copy it except
    for making a backup". If you copy it using cp and you give it to a
    friend, then *YOU* are liable. Not cp authors.

    > I am *not* saying that we shouldn't strive to have excellent and
    > consistent layout, regardless of the platform used. Traditionally,
    > WordProcessing documents have been a *poor* way of doing this, as
    > they're not really meant to. For that, we have tools like LaTeX,
    > FrameMaker, PS, PDF, et. al. What I *am* saying is that I don't like
    > the idea of embedding fonts inside of the document in order to achieve
    > this effect.


    > There are ways to achieve the behavior that you're looking for, even
    > with a tool like Abi as part of the document workflow.

    how can you get an editable document with the same look without
    embedding the font? What are these "ways"?

    > However, Abi is
    > not FrameMaker and Abi is not PDF. Abi is a word processor. There are
    > many subtle (and not-so-subtle) distinctions between all of the
    > aforementioned technologies, and what users have come to expect from
    > them.

    Ok, write down the different goals between we, and say MS Word. Word
    does font embedding. Font embedding is useful. There is no possible
    discussion about it.

    You say it may be illegal (even if everybody in the world is doing it)?
    I show you free and commercial examples of people doing it.

    Now, *WHERE* is the problem?

    Joaquín Cuenca Abela

    This archive was generated by hypermail 2.1.4 : Thu Aug 08 2002 - 18:14:17 EDT