Begin forwarded message:
> From: Dom Lachowicz <[EMAIL PROTECTED]>
> Date: Thu Aug 8, 2002 5:22:36 PM US/Eastern
> To: Joaqu�n Cuenca Abela <[EMAIL PROTECTED]>
> Subject: Re: layout/screen units mess
>
>>> 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.
>
> 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.
>
>>> 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.
>
>> 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.
>
>>> 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 http://myfontland.com";?
>>
>> 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.
>
>> 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. 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.
>
>>> 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.
>
>> 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.
>
> 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. 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.
>
>>> If you do anything, prepare to argue your case for your proposed
>>> solution, because there will be arguments for and against it, and I
>>> think that most arguments for all sides will have a 1+ kernels of
>>> truth
>>> to them.
>>
>> I'm waiting for these arguments :)
>
> Here you go ;)
>
> Dom
>
