Hey all,
I have a large number of OOo documents, and since a while my older documents look different. For example when I open invoices (since they are invoices I can't email an example document ;-) I wrote in June and fitted on one page now have 1 or 2 lines on the next page. When I open those documents with OOo 2.0.2 on windows they look correct.
This happens on my latest Rawhide (OOo 2.0.3) and on FC5 (OOo 2.0.2), is anybody else seeing this problem too ?
- Erwin
It's been this way for me since probably FC3 and still in FC5. Certain .doc files that fit perfectly on one page in Windows XP, will spread over into two pages on FC. I think it has to do with fonts, but not sure.
Benjy
On 7/6/06, Erwin Rol mailinglists@erwinrol.com wrote:
Hey all,
I have a large number of OOo documents, and since a while my older documents look different. For example when I open invoices (since they are invoices I can't email an example document ;-) I wrote in June and fitted on one page now have 1 or 2 lines on the next page. When I open those documents with OOo 2.0.2 on windows they look correct.
This happens on my latest Rawhide (OOo 2.0.3) and on FC5 (OOo 2.0.2), is anybody else seeing this problem too ?
- Erwin
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 7/6/06, Erwin Rol mailinglists@erwinrol.com wrote:
Hey all,
I have a large number of OOo documents, and since a while my older documents look different. For example when I open invoices (since they are invoices I can't email an example document ;-) I wrote in June and fitted on one page now have 1 or 2 lines on the next page. When I open those documents with OOo 2.0.2 on windows they look correct.
This happens on my latest Rawhide (OOo 2.0.3) and on FC5 (OOo 2.0.2), is anybody else seeing this problem too ?
- Erwin
On Sat, 2006-07-08 at 05:32 -0400, Benjy Grogan wrote:
It's been this way for me since probably FC3 and still in FC5. Certain .doc files that fit perfectly on one page in Windows XP, will spread over into two pages on FC. I think it has to do with fonts, but not sure.
Well that really sucks, it seems OOo is quickly reaching MS-Word quality, your documents look different every time you open them :-/
What i don't understand is why for a few months OOo on FC5 still would display the documents correctly. On rawhide i could understand it because it has 2.0.3 instead of 2.0.2, although this would still be a serious bug if documents look different in 2.0.3 compared to 2.0.2.
Sometimes you wish that ppl writing things like OOo would pay as much attention to output quality as Donald Knuth :-/ Of course ppl writing things like OOo would sometimes wish ppl would help them instead of complaining ;-)
- Erwin
Erwin Rol mailinglists@erwinrol.com wrote:
[...]
Sometimes you wish that ppl writing things like OOo would pay as much attention to output quality as Donald Knuth :-/
Problem is that "that other office package" couldn't care less about output quality, and many OOo users insist on pixel-exact rendering of the produced junk...
Of course ppl writingthings like OOo would sometimes wish ppl would help them instead of complaining ;-)
So very true.
On Sun, 2006-07-09 at 00:02 -0400, Horst von Brand wrote:
Erwin Rol mailinglists@erwinrol.com wrote:
[...]
Sometimes you wish that ppl writing things like OOo would pay as much attention to output quality as Donald Knuth :-/
Problem is that "that other office package" couldn't care less about output quality, and many OOo users insist on pixel-exact rendering of the produced junk...
We are talking about documents written with OOo 2.0.2 and opened with OOo 2.0.3 or even OOo 2.0.2 of a few updates later, that "other office package" I have not used for years and years (before OOo I used LaTeX).
It is simply not acceptable when Documents written on the same computer look different after some minor (OOo 2.0.2 -> OOo 2.0.2 + bugfix) updates look different. And worse, the documents look OK again when opened by OOo on "that other OS".
- Erwin
Erwin Rol schrieb:
On Sun, 2006-07-09 at 00:02 -0400, Horst von Brand wrote:
Erwin Rol mailinglists@erwinrol.com wrote: [...]
Sometimes you wish that ppl writing things like OOo would pay as much attention to output quality as Donald Knuth :-/
Problem is that "that other office package" couldn't care less about output quality, and many OOo users insist on pixel-exact rendering of the produced junk...
We are talking about documents written with OOo 2.0.2 and opened with OOo 2.0.3 or even OOo 2.0.2 of a few updates later, that "other office package" I have not used for years and years (before OOo I used LaTeX).
It is simply not acceptable when Documents written on the same computer look different after some minor (OOo 2.0.2 -> OOo 2.0.2 + bugfix) updates look different. And worse, the documents look OK again when opened by OOo on "that other OS".
Just FYI: I had similar problems. Is suspected it happened after this (from the changelog of the rpm):
[...] * Do Apr 27 2006 Caolan McNamara caolanm@redhat.com - 1:2.0.2-5.8 [...] - rh#189061# honour fontconfig autohint/hinting settings [...]
I never got around to look at it closer. It only happened on one of my machines (one that's not perfectly clean, so it might be a local issue...)
CU thl
On Sat, 2006-07-08 at 05:32 -0400, Benjy Grogan wrote:
It's been this way for me since probably FC3 and still in FC5. Certain .doc files that fit perfectly on one page in Windows XP, will spread over into two pages on FC. I think it has to do with fonts, but not sure.
There are a number of possible reasons, but indeed the most likely is simply that you don't have the font that the original document was written with.
Without having the same font then unless the replacement font is metrically equivalent then the text in the document is not going to be in the same place.
Now, there are two main fonts used in MS documents, Times New Roman and Arial. If you buy RHEL, or if you buy StarOffice you get either "Thorndale AMT/Thorndale" or "Albany AMT/Albany" and those are metrically equivalent to "Times New Roman" and "Arial". So if you have *those* fonts your document is likely to be exactly the same in writer as in msword, or XP vs Fedora. If you have those fonts, but still have trouble then you have something interesting that the OOo developers can examine and fix. If you don't have those fonts then you're never going to be a totally happy camper unless someone gives us some free equivalently spaced and leaded fonts. (FWIW Cumberland AMT/Cumberland is the Courier New equivalent font IIRC)
For completeness, what differentiates Fedora OOo from "stock" OOo in this area, is that we immediately ask fontconfig what is the best replacement font when the original font is not found. Stock OOo contains it's own list of guess work to fallback through. Both systems for fedora use "Nimbus No 9 Roman L" (snappy name) for "Times New Roman" fallback unless Thorndale is available, in which case that's the preferred fallback.
Some other interesting things are that
Some fonts have "leading" as in the metal strips of lead which typesetters would place between lines of type, which is a feature of the font which describes how far apart the various line of text written in that font should be placed, MS has honours this since maybe 97, and OOo honours this from 2.0.1 onwards. Both applications having compatibility flags to toggle this on and off
Both MS and writer have various compatibility flags which control some aspects of spacing between paragraphs, i.e. some versions of word combine before/after spacing of touching paragraph together by adding them, and some by finding the max of before/after and use that value instead, this is also controlled by some compatibility flags. I think I got most of them working in writer in 2.0.2 onwards. These are part of the HTML compatibility flags which word implemented to behave the same as web browsers for it's HTML import work.
There is also a little feature in word where a line of text which comprises only of whitespace, when it appears at the top of a page, is considered of less height than a line of normal text, or a line of whitespace when it appears elsewhere on a page. This one is now implemented in 2.0.3 I believe.
There is another aspect to this, which is WYSIWYG in relation to what printer is selected. This is actually also controlled by compatibility flags, since around word 2000, MS no longer cares about what your printer can and can not do, and renders according to an idealized printer backend, and stuffs that to your printer to make do the best it can. Which means that the doc is always the same on screen regardless of the printer. Writer *also* now does this, and we hope that we have gotten the right guesses as to the properties of the idealized printer. A little toggle in word and writer revert to the traditional "do what the printer can do" behaviour.
Another little gotcha is with tabs, if there is a tiny amount of space between the end of a character and the next tab stop , then when a tab is inserted a decision needs to be made if that space is sufficiently large enough for the tab to go that next tab stop, or if to skip it and move to the next one. The default value in word is much smaller than the default value in writer (or maybe it was the other way around, I think that compatibility was completed in 2.0.2, but maybe in 2.0.3). Of course if your font's aren't the same then this sort of tab staircasing is going to happen regardless of flags.
There are minor things which don't affect anything, but can confuse. e.g. There are often complaints that tables imported from word and misplaced, because the guide lines in writer that show the text boundaries in writer show that imported tables are positioned with their left corner outside the guide lines. That's because word positions tables by default so that the contained text will appear on the text boundary edge, and positions the table negatively to take into account the left and right cell paddings. Only in the horizontal direction, not the vertical one though.
For fun, here's another one. A graphic in writer is positioned and sized according to the top left of the graphic + border. So if you have a 3x3cm graphic, and put a 1cm border around it. The graphic itself is shrunk to make the result remain the same size before and after the border is added, and this overall result is still placed in accordance with the outside left corner. In word the graphic content remains the same size and the border placed outside, so the overall result is larger, but the graphic is positioned according to the top left "inside" corner of the graphic. i.e. position graphic and then draw border outside it. This gets sort of crazy though with some of the "striped" bordering styles where there are three stripes in the border, black, while, black. Word positions according to the top left corner of the *middle* stripe. Neither the inside of the graphic itself, or the outside of the border, but according to some implementation quirk of border handling.
So.... you need metrically equivalent fonts, and if you still have problems then some possibly unknown, but similar to above, "tricky to figure out the complete rules" layout quirk is affecting us.
I find the the problems are endemic to an organization due to shared templates, or more informal basing documents off eachother and other shared habits. e.g. if a template in word 6 was migrated through many word revisions it'll have the word 6 compatibility features toggled on, which aren't the current word defaults so some of the word 6 quirks remain in use in a company but aren't so prevalent for the writer .doc filter developers to see as common. So an organization tends to find writer uniformly "rubbish" or "good" depending on their word-using history. Obviously with font related spacing issues, you generally get "good" results when users use page breaks to create a new page, "bad" results when users hit return to get vertical white space until they get to a new page. In the first case the cumulative error rate is reset to 0 on every page break, in the second case the error accumulates over the entire document.
C.
Le Lun 10 juillet 2006 10:32, Caolan McNamara a écrit :
On Sat, 2006-07-08 at 05:32 -0400, Benjy Grogan wrote:
It's been this way for me since probably FC3 and still in FC5. Certain .doc files that fit perfectly on one page in Windows XP, will spread over into two pages on FC. I think it has to do with fonts, but not sure.
There are a number of possible reasons, but indeed the most likely is simply that you don't have the font that the original document was written with.
Indeed, there are many reasons why fit-to-page will never work across office suites and systems. Unless the OO.o people implement a "fit on X page" control which transparently scales text (as WordPerfect had I think).
Much more resilient and user-friendly than manually tweaking something till it fits on X pages only to discover it doesn't on the neighbour's computer. (and all the modern font substitution systems mean you don't know anything about the metrics of the fonts you use, so doing sizing manually is going to be more and more difficult)
You've forgotten the "page designed for Letter, used with A4" problem in your list. BTW
Regards,
On Mon, 2006-07-10 at 10:57 +0200, Nicolas Mailhot wrote:
Le Lun 10 juillet 2006 10:32, Caolan McNamara a écrit :
On Sat, 2006-07-08 at 05:32 -0400, Benjy Grogan wrote:
It's been this way for me since probably FC3 and still in FC5. Certain .doc files that fit perfectly on one page in Windows XP, will spread over into two pages on FC. I think it has to do with fonts, but not sure.
There are a number of possible reasons, but indeed the most likely is simply that you don't have the font that the original document was written with.
Indeed, there are many reasons why fit-to-page will never work across office suites and systems. Unless the OO.o people implement a "fit on X page" control which transparently scales text (as WordPerfect had I think).
Much more resilient and user-friendly than manually tweaking something till it fits on X pages only to discover it doesn't on the neighbour's computer. (and all the modern font substitution systems mean you don't know anything about the metrics of the fonts you use, so doing sizing manually is going to be more and more difficult)
You've forgotten the "page designed for Letter, used with A4" problem in your list. BTW
I hate to repeat myself but, i was not doing any cross-office-suit stuff, nor doing A4<->letter, nor using different platforms, I wrote my documents on FC5 with OOo 2.0.2 and now a few "yum updates" later i open my documents with OOo 2.0.2 and they look different.
Anny excuse about not possible to write documents on different platforms etc. not being possible is a joke anyway. When a ODF document is suppose to be the new hype for document management all over the world and for all times there better be programs that can actually display the documents correctly in a few years on different platforms. As it is now it is not even possible after a few months on the same platform.
And before someone says this is an OOo problem and not a fedora problem, than it should also display incorrect on Windows and that's not the case, on windows the documents look correct.
- Erwin
Le lundi 10 juillet 2006 à 18:36 +0200, Erwin Rol a écrit :
When a ODF document is suppose to be the new hype for document management all over the world and for all times there better be programs that can actually display the documents correctly in a few years on different platforms. As it is now it is not even possible after a few months on the same platform.
The document *is* displaying correctly. Unless you've explicitely specified "it must fit on X pages" somewhere (and current OO.o does not allow this) *nothing* will ensure its pagination does not change slightly over time. The first thing OO.o or Office do when loading a doc is to repaginate it, precisely because font sizes are not invariants.
You want pixel or page-perfect rendering you export your doc as PDF with embedded fonts. Or you make OO.o implement fixed-number-of-pages scaling.
The sad thing is people don't care about what you're asking - if they did word processing would not have rolled over DTP in the last decade. In a word processing context all you have is a text flow (as in free-flow).
And before someone says this is an OOo problem and not a fedora problem, than it should also display incorrect on Windows and that's not the case, on windows the documents look correct.
You write the document in Fedora with Fedora fonts you'll see if it displays correctly on windows.
On 7/10/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le lundi 10 juillet 2006 à 18:36 +0200, Erwin Rol a écrit :
When a ODF document is suppose to be the new hype for document management all over the world and for all times there better be programs that can actually display the documents correctly in a few years on different platforms. As it is now it is not even possible after a few months on the same platform.
The document *is* displaying correctly. Unless you've explicitely specified "it must fit on X pages" somewhere (and current OO.o does not allow this) *nothing* will ensure its pagination does not change slightly over time. The first thing OO.o or Office do when loading a doc is to repaginate it, precisely because font sizes are not invariants.
You want pixel or page-perfect rendering you export your doc as PDF with embedded fonts. Or you make OO.o implement fixed-number-of-pages scaling.
The sad thing is people don't care about what you're asking - if they did word processing would not have rolled over DTP in the last decade. In a word processing context all you have is a text flow (as in free-flow).
People do care. I've heard this complaint before. It's not a concern when a 27 page document becomes a 28 page document, but when you want to have 1 page and suddenly that 1 page has become 2 pages and you're searching for what OS it last fit properly on, then it gets to be a nuisance.
I have a C. Vitae that I can't edit in Fedora because it takes up 2 pages there but in Windows XP it will only take up 1 page, which is right on.
I'd be happy with a set of fonts that work the same on all OSes, and then I'd stick with those. Times New Roman seems like a hassle now.
Benjy
And before someone says this is an OOo problem and not a fedora problem, than it should also display incorrect on Windows and that's not the case, on windows the documents look correct.
You write the document in Fedora with Fedora fonts you'll see if it displays correctly on windows.
-- Nicolas Mailhot
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux)
iEYEABECAAYFAkSyjdsACgkQI2bVKDsp8g1pXACeLapvRO4pQPFbLZTMCtZSDhju 7PUAoPfX5DJiorK7LgnjBTzE3g139k96 =wQE1 -----END PGP SIGNATURE-----
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Le lundi 10 juillet 2006 à 13:44 -0400, Benjy Grogan a écrit :
On 7/10/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
The sad thing is people don't care about what you're asking - if they did word processing would not have rolled over DTP in the last decade. In a word processing context all you have is a text flow (as in free-flow).
People do care. I've heard this complaint before. It's not a concern when a 27 page document becomes a 28 page document, but when you want to have 1 page and suddenly that 1 page has become 2 pages and you're searching for what OS it last fit properly on, then it gets to be a nuisance.
Well, they don't care enough to buy DTP products, which means word is the only game in town, and writer is just emulating it.
I'd be happy with a set of fonts that work the same on all OSes, and then I'd stick with those. Times New Roman seems like a hassle now.
Even with a single common font you'd have problems : - some other parts of the formatting will have fuzzy definition interpreted slightly differently over time by different software versions. - every system won't interpret the same font the same way (currently Fedora won't use the bytecode interpreter because of patent concerns, Windows will) - fonts are not static : they include instructions for the rendering engines, and as rendering engines get smarter font designers include more complex instructions, which mean display and print approach progressively the font designer ideal, but the size of a given text string will change as a result.
The page change the poster is complaining about is due to Fedora honoring some font settings it ignored before.
Right now the only game in town if you don't use a DTP-like product with transparent fit-to-frame scaling is to reserve enough blank space on the page to account to the slight rendering variations between office suites.
Regards,
On Mon, 2006-07-10 at 20:26 +0200, Nicolas Mailhot wrote:
Le lundi 10 juillet 2006 à 13:44 -0400, Benjy Grogan a écrit :
On 7/10/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
The sad thing is people don't care about what you're asking - if they did word processing would not have rolled over DTP in the last decade. In a word processing context all you have is a text flow (as in free-flow).
People do care. I've heard this complaint before. It's not a concern when a 27 page document becomes a 28 page document, but when you want to have 1 page and suddenly that 1 page has become 2 pages and you're searching for what OS it last fit properly on, then it gets to be a nuisance.
Well, they don't care enough to buy DTP products, which means word is the only game in town, and writer is just emulating it.
I'd be happy with a set of fonts that work the same on all OSes, and then I'd stick with those. Times New Roman seems like a hassle now.
Even with a single common font you'd have problems :
- some other parts of the formatting will have fuzzy definition
interpreted slightly differently over time by different software versions.
- every system won't interpret the same font the same way (currently
Fedora won't use the bytecode interpreter because of patent concerns, Windows will)
- fonts are not static : they include instructions for the rendering
engines, and as rendering engines get smarter font designers include more complex instructions, which mean display and print approach progressively the font designer ideal, but the size of a given text string will change as a result.
those are all technical reasons, here we (with we I mean software developers, and that includes me) are trying again to find a excuse to not make what the user wants. I would dare to bet with you that most users expect their ODF (or DOC) documents to look the same even if they open them 5 years later with a new version of OOo or Word (of course for some documents they might say "oh well strange that it is now 26 instead of 25 pages, but of well, probably just a little bug in my new version of Word").
The page change the poster is complaining about is due to Fedora honoring some font settings it ignored before.
What ever the reason is, the software's way of working changed in a bad way, so this "fix" did not fix anything it broke things.
Right now the only game in town if you don't use a DTP-like product with transparent fit-to-frame scaling is to reserve enough blank space on the page to account to the slight rendering variations between office suites.
Not an option for multi-page documents. BTW differently rendered multi-page documents can be very confusing too, for example think about a meeting where 3 ppl open a document, one on a mac, one on windows one on XP, and than say; "Now all look at page 25 where you will see ...." good luck finding out where the text is that is shown on page 25 by one of the ppl.
For me, not rendering documents correct in a word processing application is a _fatal_ bug. Changing the way old documents are rendered is even more fatal. Copying this behavior from Microsoft (if Word even has that behavior which i would not dare to bet about!) is not a good thing to do.
But since i have no idea how to fix it, I will not continue to bug ppl with it. And sounding by the arguments on why it is displaying documents incorrect it seems OOo is just broken by design, so there is nothing easy to fix in the first place.
- Erwin
On 7/10/06, Erwin Rol mailinglists@erwinrol.com wrote:
those are all technical reasons, here we (with we I mean software developers, and that includes me) are trying again to find a excuse to not make what the user wants. I would dare to bet with you that most users expect their ODF (or DOC) documents to look the same even if they open them 5 years later with a new version of OOo or Word (of course for some documents they might say "oh well strange that it is now 26 instead of 25 pages, but of well, probably just a little bug in my new version of Word").
People can want that.. but it is an upstream issue. I have had many Word 95 documents not do the right thing when being displayed in Word 2000 or Word XP. Fonts change, DPI changed and if the author was trying to be clever it just doesnt happen correctly. Heck I have had pdf's show up oddly if a font changed on the system.
There are too many failure modes in software upgrades which is why some document systems bundled the fonts and layout engine with the document. This way the system is 'guarenteed' to have 99% reliability of showing the document the same each time. The documents also bloat up like popcorn bags.
Στις 10-07-2006, ημέρα Δευ, και ώρα 20:54 +0200, ο/η Erwin Rol έγραψε:
On Mon, 2006-07-10 at 20:26 +0200, Nicolas Mailhot wrote:
Le lundi 10 juillet 2006 à 13:44 -0400, Benjy Grogan a écrit :
On 7/10/06, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
The sad thing is people don't care about what you're asking - if they did word processing would not have rolled over DTP in the last decade. In a word processing context all you have is a text flow (as in free-flow).
People do care. I've heard this complaint before. It's not a concern when a 27 page document becomes a 28 page document, but when you want to have 1 page and suddenly that 1 page has become 2 pages and you're searching for what OS it last fit properly on, then it gets to be a nuisance.
Well, they don't care enough to buy DTP products, which means word is the only game in town, and writer is just emulating it.
I'd be happy with a set of fonts that work the same on all OSes, and then I'd stick with those. Times New Roman seems like a hassle now.
Even with a single common font you'd have problems :
- some other parts of the formatting will have fuzzy definition
interpreted slightly differently over time by different software versions.
- every system won't interpret the same font the same way (currently
Fedora won't use the bytecode interpreter because of patent concerns, Windows will)
- fonts are not static : they include instructions for the rendering
engines, and as rendering engines get smarter font designers include more complex instructions, which mean display and print approach progressively the font designer ideal, but the size of a given text string will change as a result.
those are all technical reasons, here we (with we I mean software developers, and that includes me) are trying again to find a excuse to not make what the user wants. I would dare to bet with you that most users expect their ODF (or DOC) documents to look the same even if they open them 5 years later with a new version of OOo or Word (of course for some documents they might say "oh well strange that it is now 26 instead of 25 pages, but of well, probably just a little bug in my new version of Word").
The page change the poster is complaining about is due to Fedora honoring some font settings it ignored before.
What ever the reason is, the software's way of working changed in a bad way, so this "fix" did not fix anything it broke things.
Right now the only game in town if you don't use a DTP-like product with transparent fit-to-frame scaling is to reserve enough blank space on the page to account to the slight rendering variations between office suites.
Not an option for multi-page documents. BTW differently rendered multi-page documents can be very confusing too, for example think about a meeting where 3 ppl open a document, one on a mac, one on windows one on XP, and than say; "Now all look at page 25 where you will see ...." good luck finding out where the text is that is shown on page 25 by one of the ppl.
For me, not rendering documents correct in a word processing application is a _fatal_ bug. Changing the way old documents are rendered is even more fatal. Copying this behavior from Microsoft (if Word even has that behavior which i would not dare to bet about!) is not a good thing to do.
But since i have no idea how to fix it, I will not continue to bug ppl with it. And sounding by the arguments on why it is displaying documents incorrect it seems OOo is just broken by design, so there is nothing easy to fix in the first place.
It's difficult to say without seeing some sample documents. It's common that some documents are written in such a way that makes them fragile to slight variations of system settings.
For example, there are documents that are written without specifying styles; to make the pagination they use blank lines instead of page breaks.
Having some minimal sample docs would be great to pinpoint issues.
Simos
Le lundi 10 juillet 2006 à 20:54 +0200, Erwin Rol a écrit :
On Mon, 2006-07-10 at 20:26 +0200, Nicolas Mailhot wrote:
The page change the poster is complaining about is due to Fedora honoring some font settings it ignored before.
What ever the reason is, the software's way of working changed in a bad way, so this "fix" did not fix anything it broke things.
If bad = it changed just freeze your hardware and software and nothing bad will ever happen to you.
Right now the only game in town if you don't use a DTP-like product with transparent fit-to-frame scaling is to reserve enough blank space on the page to account to the slight rendering variations between office suites.
Not an option for multi-page documents.
"Frame" in a DTP context can extend on several pages
BTW differently rendered multi-page documents can be very confusing too, for example think about a meeting where 3 ppl open a document, one on a mac, one on windows one on XP, and than say; "Now all look at page 25 where you will see ...."
This is why read-only formats like pdf exist
good luck finding out where the text is that is shown on page 25 by one of the ppl.
This is why all serious writers use lawyer-style continuous numbering
For me, not rendering documents correct in a word processing application is a _fatal_ bug.
Either you can use static documents and pdf will be fine for you and you want editable documents.
Now consider this : 1. you have a document saved on X pages 2. several years later, office suite opens it and recognizes it was saved on X pages, so even it it would have rendered it by itself on Y pages it scales it to X pages 3. user starts typing. Now what. Should the suite disable scaling? Try to keep the document on X pages, continuously scaling? At which point should it disable scaling? Can't make a good decision, because it does not know if the user cares more about the page number or the font size/line spacing/word spacing (and some institutions mandate a particular font size). This is basically a no-win can't-secondguess-user situation
In DTP-like scaling is explicitly requested by the users which makes it safe.
If you want scaling in OO.o it needs to be explicit too to work (probably in format/page/fit on X pages and apply to whole document or section only).
Good luck getting it implemented - the OO.o guys are so busy cleaning up the old staroffice code and getting feature-parity with office features office lacks are very low on their agenda
Changing the way old documents are rendered is even more fatal. Copying this behavior from Microsoft (if Word even has that behavior which i would not dare to bet about!) is not a good thing to do.
Word has this behaviour too because it's impossible to implement sanely without user hints, and even with them it's non-trivial.
Sure users expect something else. Users expect the behaviour of print output without the static nature of printout. Users expect magic. That's now how software works. -ENOTELEPATHY
But since i have no idea how to fix it, I will not continue to bug ppl with it.
At least bug people the right way by opening a bug in OO.o issuezilla and writing an implementation spec.
On Mon, 2006-07-10 at 22:20 +0200, Nicolas Mailhot wrote:
But since i have no idea how to fix it, I will not continue to bug
ppl
with it.
At least bug people the right way by opening a bug in OO.o issuezilla and writing an implementation spec.
Well it ended here because it did happen on FC5 and rawhide but not on Windows. So it seemed that OOo worked correctly and FC changed something that made it not work correctly on FC.
- Erwin
On Mon, Jul 10, 2006 at 10:53:52PM +0200, Erwin Rol wrote:
Well it ended here because it did happen on FC5 and rawhide but not on Windows. So it seemed that OOo worked correctly and FC changed something that made it not work correctly on FC.
Can you please describe what "it" is? Does the file:
1) Take up the same number of pages in both Windows and FC5, but is different in Rawhide? 2) Take up the same number of pages in Windows and Rawhide, but change between FC5 and Rawhide? 3) Or something else?
Do you have examples of files which render differently in FC5 and Rawhide and Windows? There were changes done to rendering between FC5 and Rawhide to use font information that Windows has always (supposedly) used that FC5 and earlier don't use. Hypothetically this should actually make the rendering in Rawhide closer to that of Windows, though there are a host of other possibilities that would cause rendering differences because OOo, just like Word which it is based on, is inherently suspectible to this sort of thing. I've certainly seen pagination differences when upgrading between versions of Word, or between releases of Windows.
Hypothetically, if OOo in FC5 rendered differently than on Windows, would you consider it a bug or a problem if it were changed for FC6 to render closer (even identical) to Windows but this made it different from FC5 and earlier?
John Thacker
On Mon, 2006-07-10 at 17:37 -0400, John Thacker wrote:
On Mon, Jul 10, 2006 at 10:53:52PM +0200, Erwin Rol wrote:
Well it ended here because it did happen on FC5 and rawhide but not on Windows. So it seemed that OOo worked correctly and FC changed something that made it not work correctly on FC.
Can you please describe what "it" is? Does the file:
- Take up the same number of pages in both Windows and FC5, but is
different in Rawhide? 2) Take up the same number of pages in Windows and Rawhide, but change between FC5 and Rawhide? 3) Or something else?
OK maybe not exactly what you were looking for, but attached is a Gimp image with two layers. (OK attachment was to big and the mail bounced; picture can be found at http://www.erwinrol.com/ooo.xcf) By changing the alpha channel of the "FC Rawhide" layer you can fade the XP rendering and the FC rendering. I whited out things like prices, bankaccounts and client name/address. This shows how the font height has changed a lot. The older FC3, FC4,FC5 and rawhide systems all rendered the page like XP is still doing.These pictures are screenshots from a 1600x1200 display, OOo displayed the document at 75% zoom. As you can see the width is almost pixel perfect.
Hypothetically, if OOo in FC5 rendered differently than on Windows, would you consider it a bug or a problem if it were changed for FC6 to render closer (even identical) to Windows but this made it different from FC5 and earlier?
I see a WYSIWYG word processor like a painting program. When I create a painting with gimp, I expect it to look the same when I open it with photoshop. Of course there might be tiny difference like photoshop might use another JPG decoder and so maybe some pixels have a bit of a difference. If i would not want this i should use another picture format. The same with word processors, there might be some tiny differences in how the font is rendered, but not like now that one page fits about 5 lines less (that are than move to the next page).
Now earlier FC5 and Windows look almost the same, but newer FC5 and Rawhide look very different from Windows and earlier FC5.
- Erwin
Le mardi 11 juillet 2006 à 01:38 +0200, Erwin Rol a écrit :
Hypothetically, if OOo in FC5 rendered differently than on Windows, would you consider it a bug or a problem if it were changed for FC6 to render closer (even identical) to Windows but this made it different from FC5 and earlier?
I see a WYSIWYG word processor like a painting program. When I create a painting with gimp, I expect it to look the same when I open it with photoshop. Of course there might be tiny difference like photoshop might use another JPG decoder and so maybe some pixels have a bit of a difference. If i would not want this i should use another picture format. The same with word processors, there might be some tiny differences in how the font is rendered, but not like now that one page fits about 5 lines less (that are than move to the next page).
An office document is not a bitmap and the WYSIWYG part has always been more a best effort thing than a hard commitment.
An office document is a set of construction rules. This is why you have individual hight-level components (characters) you can change later. Try that with a jpg where pixels are frozen and shapes are not shapes you can manipulate but collections of pixels.
On Tue, 2006-07-11 at 08:23 +0200, Nicolas Mailhot wrote:
Le mardi 11 juillet 2006 à 01:38 +0200, Erwin Rol a écrit :
Hypothetically, if OOo in FC5 rendered differently than on Windows, would you consider it a bug or a problem if it were changed for FC6 to render closer (even identical) to Windows but this made it different from FC5 and earlier?
I see a WYSIWYG word processor like a painting program. When I create a painting with gimp, I expect it to look the same when I open it with photoshop. Of course there might be tiny difference like photoshop might use another JPG decoder and so maybe some pixels have a bit of a difference. If i would not want this i should use another picture format. The same with word processors, there might be some tiny differences in how the font is rendered, but not like now that one page fits about 5 lines less (that are than move to the next page).
An office document is not a bitmap and the WYSIWYG part has always been more a best effort thing than a hard commitment.
An office document is a set of construction rules. This is why you have individual hight-level components (characters) you can change later. Try that with a jpg where pixels are frozen and shapes are not shapes you can manipulate but collections of pixels.
Once again, you can give 1000 technical reasons or metaphors, my expectation (and that of several others) is that OOo should be able to reproduce a saved document in the same way it looked when it was created.
And apart from not reproducing the document correctly, it also now renders text extremely ugly with the big font height, there ends up way to much space between the lines.
- Erwin
On Tue, 2006-07-11 at 09:17 +0200, Erwin Rol wrote:
Once again, you can give 1000 technical reasons or metaphors, my expectation (and that of several others) is that OOo should be able to reproduce a saved document in the same way it looked when it was created.
Open a bug on fedora bugzilla against OOo, attach a sample document which has changed, mention the version of OOo/FC where it worked, and the one where it didn't and I'll find out the exact problem.
C.
On 7/11/06, Erwin Rol mailinglists@erwinrol.com wrote:
On Tue, 2006-07-11 at 08:23 +0200, Nicolas Mailhot wrote:
Le mardi 11 juillet 2006 à 01:38 +0200, Erwin Rol a écrit :
Once again, you can give 1000 technical reasons or metaphors, my expectation (and that of several others) is that OOo should be able to reproduce a saved document in the same way it looked when it was created.
Ok how about this. Your expectation is too high for what a WYSIWYG editor can do.
This is the reason that PDF/Postscript is the preferred structure for many legal documents because you have greater than 95% assurance it will look the same on all platforms/boxes. Word, Wordperfect and Office are in the best effort category (80-90% assurance). I work in a very large organization (>40,000 people) and we have problems with someone with Word XP in Washington sending documents to someone in California with Word XP and the documents not being exactly the same. This is what led to having Acrobat being the render engine for forms and legal documents.
There are very few WYSIWYG editors that actually can produce greater than 95% assurance.. and they are the ones that pretty much ship the 'fonts+render engine+preferences' (basically it was the 1980's form of vmplayer with the editor set up in it).
And apart from not reproducing the document correctly, it also now renders text extremely ugly with the big font height, there ends up way to much space between the lines.
That would be a bug for bugzilla with a sample document that produces it, what fonts you have installed on the system, and what your font preferences are set in GNOME or KDE (dependign on what you are using).
On Tue, 2006-07-11 at 08:23 +0200, Nicolas Mailhot wrote:
An office document is not a bitmap and the WYSIWYG part has always been more a best effort thing than a hard commitment.
WYSIWYG means "Will print out right *now* exactly like it looks on screen right *now*". It has nothing to do with "Will look exactly the same when opened on a completely different software package on a completely different operating system" or "Will look the same when opened five years later".
Erwin Rol <mailinglists <at> erwinrol.com> writes:
OK maybe not exactly what you were looking for, but attached is a Gimp image with two layers. (OK attachment was to big and the mail bounced; picture can be found at http://www.erwinrol.com/ooo.xcf)
That really looks like it's using two completely different fonts (with different metrics) and of course that's messing up the formatting. But don't ask me why.
Kevin Kofler
Caolan McNamara wrote:
For completeness, what differentiates Fedora OOo from "stock" OOo in this area, is that we immediately ask fontconfig what is the best replacement font when the original font is not found. Stock OOo contains it's own list of guess work to fallback through.
Do we have a list of differences in the Fedora OO.o from upstream OO.o?
Rahul
Στις 10-07-2006, ημέρα Δευ, και ώρα 14:30 +0530, ο/η Rahul έγραψε:
Caolan McNamara wrote:
For completeness, what differentiates Fedora OOo from "stock" OOo in this area, is that we immediately ask fontconfig what is the best replacement font when the original font is not found. Stock OOo contains it's own list of guess work to fallback through.
Do we have a list of differences in the Fedora OO.o from upstream OO.o?
It would also be good to see test documents that demonstrate the issue.
I have noticed in some situations when you have text in different styles, in a font like Arial, in a Doc file: [regular][bold][regular], they overlap each other. Fontconfig substitutes correctly Aria to the system font in Linux, but it displays it erroneously. When you manually set the three segments above to the Linux font, they are shown well (very well).
We need minimal test documents.
Simos
On Mon, 2006-07-10 at 11:53 +0100, Simos Xenitellis wrote:
Στις 10-07-2006, ημέρα Δευ, και ώρα 14:30 +0530, ο/η Rahul έγραψε:
Caolan McNamara wrote:
For completeness, what differentiates Fedora OOo from "stock" OOo in this area, is that we immediately ask fontconfig what is the best replacement font when the original font is not found. Stock OOo contains it's own list of guess work to fallback through.
Do we have a list of differences in the Fedora OO.o from upstream OO.o?
It would also be good to see test documents that demonstrate the issue.
I have noticed in some situations when you have text in different styles, in a font like Arial, in a Doc file: [regular][bold][regular], they overlap each other. Fontconfig substitutes correctly Aria to the system font in Linux, but it displays it erroneously. When you manually set the three segments above to the Linux font, they are shown well (very well).
Indeed, you need to log these problems against bugzilla, with reproducable examples, I've never seen this or even heard of it before.
C.
-
Benjy Grogan -
Callum Lerwick -
Caolán McNamara -
Erwin Rol -
Horst H. von Brand -
John Thacker -
Kevin Kofler -
Nicolas Mailhot -
Rahul Sundaram -
Simos Xenitellis -
Stephen John Smoogen -
Thorsten Leemhuis