[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 140546] Koffice don't embed fonts during printing Koffice don't
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-01-25 9:30:23
Message-ID: 20070125093023.17064.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=140546         




------- Additional Comments From mail dipe org  2007-01-25 10:30 -------
Wow, lot of text with a lot of different topics in it :)

I guess the most interesting part (at least for me) is this use-case;

[quote]
The case here is simple: only 1 font (Vera Serif), only one size (11 pt), only one \
standard document format (ODT) -- but still 2 different applications show the \
different font rendering *even* *on* *screen* [/quote]

* Why does this happen, exactly?
Looking at the screenshots it seems the exact same line of text has different lengths \
at OOo/KWord. Hmmm...

* How could this be solved, theoretically? 
Figure out why the above is the case + fix it :) At least it would be a first step.

* Is there anybody around who is interested to do it practically too? 
I guess devels are concentrated on the work done in trunk right now. And trunk is not \
ready yet to be compared to 1.6 (e.g. OpenDoc-code is in place but not enabled yet).

* What is the effort + timeframe for that then? 
That depends on what needs to be done and how it could be done. But I would expect a \
lot of days if not weeks...

* Is that all really dependent on Qt's buggy PostScript export? 
Well, as we are able to see at the screenshots, there seems to be a difference at the \
length of the textlines already. btw, did you define the same pagemargin/etc. \
settings for both of them?

* Can't KOffice cooperate with Scribus, and use their stuff? 
1) someone needs to look at there code and compare it with our to get an impression \
of the time needed, 2) someone needs to implement it if possible/useful or fix "it", \
3) we need to define who someone is :)

Sounds for me like a lot of work... and sounds for me like it should be done on trunk \
by "someone" cause the whole textengine did switch between 1.6 and 2.0


[prev in list] [next in list] [prev in thread] [next in thread]