Am 17.01.2011 um 22:59 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> At the first glance it looks not really helpful. :(
>>
>> 1) Constructor of GuiFontInfo in GuiFontLoader.cpp start with
>>
>> GuiFontInfo::GuiFontInfo(FontInfo const & f)
>> : metrics(QFont())
>> {
>> font.setKerning(
Stephan Witt wrote:
> At the first glance it looks not really helpful. :(
>
> 1) Constructor of GuiFontInfo in GuiFontLoader.cpp start with
>
> GuiFontInfo::GuiFontInfo(FontInfo const & f)
> : metrics(QFont())
> {
> font.setKerning(false);
>
> 2) I checked the actual kerning in GuiPa
Am 17.01.2011 um 21:10 schrieb Stephan Witt:
> Am 17.01.2011 um 20:14 schrieb Pavel Sanda:
>
>> Bernhard Roider wrote:
>>> just an idea: the method QTextCharFormat::setFontKerning can enable/disable
>>> kerning. Could that help?
>>
>> i dont know if QTextCharFormat is related to our painting,
>
Am 17.01.2011 um 20:14 schrieb Pavel Sanda:
> Bernhard Roider wrote:
>> just an idea: the method QTextCharFormat::setFontKerning can enable/disable
>> kerning. Could that help?
>
> i dont know if QTextCharFormat is related to our painting,
It isn't, but perhaps it's good idea anyway. Thanks, Ber
Bernhard Roider wrote:
> just an idea: the method QTextCharFormat::setFontKerning can enable/disable
> kerning. Could that help?
i dont know if QTextCharFormat is related to our painting, but if so,
this could properly solve the issues with wrong paitning of ligatures we have.
pavel
just an idea: the method QTextCharFormat::setFontKerning can enable/disable
kerning. Could that help?
bernhard
On 13. jan. 2011 09:07, Abdelrazak Younes wrote:
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing is done with complete text strings and if a font
On Sat, Jan 15, 2011 at 11:35:14AM +0100, Jean-Marc Lasgouttes wrote:
> Le 13 janv. 2011 à 18:44, Andre Poenitz a écrit :
> >> 1) compute the metrics 8 times for a word of 8 letters 2) draw
> >> letter by letter all the times. 3) or rely on more on Qt widgets
> >> (i.e. use QTextEdit) instead on d
Le 13 janv. 2011 à 18:44, Andre Poenitz a écrit :
>> 1) compute the metrics 8 times for a word of 8 letters
>> 2) draw letter by letter all the times.
>> 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on
>> doing our thing.
>
> 4) Compute the metrics for a word twice, once as a whol
On Thu, Jan 13, 2011 at 09:07:46AM +0100, Abdelrazak Younes wrote:
> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
> >Stephan Witt wrote:
> >>The metrics cache computes the width of every single character -
> >>inclusive cacheing of it (to get better performance). But the
> >>drawing is done with comp
Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
>> Stephan Witt wrote:
>>> The metrics cache computes the width of every single character -
>>> inclusive cacheing of it (to get better performance). But the
>>> drawing is done with complete text string
On 01/13/2011 06:44 PM, Andre Poenitz wrote:
On Thu, Jan 13, 2011 at 09:07:46AM +0100, Abdelrazak Younes wrote:
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance).
On 01/14/2011 04:55 PM, Stephan Witt wrote:
Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing i
Abdelrazak Younes wrote:
>> i dont know whether multithreading app must run on a single core
>> (because data are in the same address space?) or its shortcomming
>> of the implementaion we use.
>
> Neither of the two. The kernel chooses which tasks go where. Maybe your
> system is misconfigured...
On 01/13/2011 12:44 PM, Pavel Sanda wrote:
Peter Kümmel wrote:
1) would be costly in terms of performance
But aren't we in the times of "bored cores"? Technically it is
but the load _is_ not distributed for one lyx instance, so its
equal to the situation when you have one core. even stranger a
Peter Kümmel wrote:
> > 1) would be costly in terms of performance
>
> But aren't we in the times of "bored cores"? Technically it is
but the load _is_ not distributed for one lyx instance, so its
equal to the situation when you have one core. even stranger and
i have already written about it - e
On 01/13/2011 10:05 AM, Jean-Marc Lasgouttes wrote:
Le 13 janv. 2011 à 09:42, Stephan Witt a écrit :
Am 13.01.2011 um 09:33 schrieb Pavel Sanda:
Abdelrazak Younes wrote:
To be on the save side - if nothing else is changed - you have to draw
letter by letter all the times anyway.
The option can
Le 13 janv. 2011 à 09:42, Stephan Witt a écrit :
Am 13.01.2011 um 09:33 schrieb Pavel Sanda:
>
>> Abdelrazak Younes wrote:
To be on the save side - if nothing else is changed - you have to draw
letter by letter all the times anyway.
>>>
>>> The option can set to true by default.
>>
>>
Am 13.01.2011 um 09:33 schrieb Pavel Sanda:
> Abdelrazak Younes wrote:
>>> To be on the save side - if nothing else is changed - you have to draw
>>> letter by letter all the times anyway.
>>
>> The option can set to true by default.
>
> i also wonder what the 'few more cpu cycles' mean. we are
>>> See ticket http://www.lyx.org/trac/ticket/6920
> There are three solutions:
>
> 1) compute the metrics 8 times for a word of 8 letters
> 2) draw letter by letter all the times.
> 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on doing
> our thing.
>
> 1) would be costly in te
Am 13.01.2011 um 09:28 schrieb Abdelrazak Younes:
> On 01/13/2011 09:23 AM, Stephan Witt wrote:
>> Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
>>
>>> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
> The metrics cache computes the width of every single character -
>>
Abdelrazak Younes wrote:
>> To be on the save side - if nothing else is changed - you have to draw
>> letter by letter all the times anyway.
>
> The option can set to true by default.
i also wonder what the 'few more cpu cycles' mean. we are already quite slow
at rendering...
pavel
On 01/13/2011 09:23 AM, Stephan Witt wrote:
Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing i
Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
>> Stephan Witt wrote:
>>> The metrics cache computes the width of every single character -
>>> inclusive cacheing of it (to get better performance). But the
>>> drawing is done with complete text string
This is fixed some while ago already. It mean adding 2 commas and 2 spaces and
2 commas ;), and I reported it to Qt as a little inconvenience.
Apparently, the fix didn't fix it for MacOsX ? Or haven't anyone checked yet.
I'm glad I can resolve "the most annoying bug" within 9 minutes.
Unfort
Abdelrazak Younes wrote:
> 1) would be costly in terms of performance
> 2) would add be need a bit more cpu and would have the side effect that
> kerning would not be as good Qt's word drawing. This is what we do already
> for arabic and hebrew.
> 3) is a very big task and an entirely unknown ter
Stephan Witt wrote:
> Bug 7235 isn't a duplicate of 6920. It's completely different.
sorry i mixed up things! this is indeed different bug.
pavel
Am 13.01.2011 um 08:57 schrieb Vincent van Ravesteijn:
> Op 13-1-2011 8:48, Pavel Sanda schreef:
>> Stephan Witt wrote:
>>> The metrics cache computes the width of every single character -
>>> inclusive cacheing of it (to get better performance). But the
>>> drawing is done with complete text stri
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing is done with complete text strings and if a font supports
kerning e.g. it's absolutely correct to
Op 13-1-2011 8:48, Pavel Sanda schreef:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing is done with complete text strings and if a font supports
kerning e.g. it's absolutely correct to re
Stephan Witt wrote:
> The metrics cache computes the width of every single character -
> inclusive cacheing of it (to get better performance). But the
> drawing is done with complete text strings and if a font supports
> kerning e.g. it's absolutely correct to respect it on drawing.
>
> LyX cursor
Am 10.01.2011 um 20:37 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> To me that looked strange at first. But I've found another factor to
>> "control" the misbehavior of LyX + Qt 4.7.1: change the screen zoom factor.
>
> maybe report it on qt bugzilla?
I'm not sure... I read some parts of the qt
Stephan Witt wrote:
> To me that looked strange at first. But I've found another factor to
> "control" the misbehavior of LyX + Qt 4.7.1: change the screen zoom factor.
maybe report it on qt bugzilla?
pavel
Am 08.01.2011 um 18:56 schrieb Peter Kuemmel:
> I've also managed it to build LyX on OSX.
Fine.
> I've installed the 4.7.1 dmg for Cocoa from the Trolls, 10.6.6, and GCC 4.2.
> (There was never a other Qt on the machine)
>
> What I see is something like this when using
> - Times New Roman:
> m
I've also mannaged it to build LyX on OSX.
I've installed the 4.7.1 dmg for Cocoa from the Trolls, 10.6.6, and GCC 4.2.
(There was never a other Qt on the machine)
What I see is something like this when using
- Times New Roman:
m |
- Arial or Helvetica
m
Am 06.01.2011 um 22:55 schrieb Stephan Witt:
> Am 06.01.2011 um 22:26 schrieb Peter Kümmel:
>
>> On 06.01.2011 22:18, Peter Kümmel wrote:
>>> On 06.01.2011 22:02, BH wrote:
On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt wrote:
> Am 06.01.2011 um 19:21 schrieb BH:
>
>> On Thu, Jan
Am 06.01.2011 um 22:26 schrieb Peter Kümmel:
> On 06.01.2011 22:18, Peter Kümmel wrote:
>> On 06.01.2011 22:02, BH wrote:
>>> On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt wrote:
Am 06.01.2011 um 19:21 schrieb BH:
> On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote:
>> Am 06.
On 06.01.2011 22:18, Peter Kümmel wrote:
> On 06.01.2011 22:02, BH wrote:
>> On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt wrote:
>>> Am 06.01.2011 um 19:21 schrieb BH:
>>>
On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote:
> Am 06.01.2011 um 16:13 schrieb BH:
>
Yes -- cur
On 06.01.2011 22:02, BH wrote:
> On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt wrote:
>> Am 06.01.2011 um 19:21 schrieb BH:
>>
>>> On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote:
Am 06.01.2011 um 16:13 schrieb BH:
>>>
>>> Yes -- current svn with Qt-4.7.1 (Carbon, 32 bit). I'm on OS
On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt wrote:
> Am 06.01.2011 um 19:21 schrieb BH:
>
>> On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote:
>>> Am 06.01.2011 um 16:13 schrieb BH:
>>>
>>
>> Yes -- current svn with Qt-4.7.1 (Carbon, 32 bit). I'm on OS X 10.6.5,
>> using the 10.5 SDK.
>
> OS
Am 06.01.2011 um 19:21 schrieb BH:
> On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote:
>> Am 06.01.2011 um 16:13 schrieb BH:
>>
>
> Yes -- current svn with Qt-4.7.1 (Carbon, 32 bit). I'm on OS X 10.6.5,
> using the 10.5 SDK.
OS X 10.6.5, Qt-4.7.1 (Carbon, 32 bit), 10.5 SDK.
It's all the sam
On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote:
> Am 06.01.2011 um 16:13 schrieb BH:
>
>> This is a follow-up to problems we've had with on-screen display of
>> fonts, where the spacing between words and cursor position was not
>> calculated correctly due to ligatures, swooshes, or other font
Am 06.01.2011 um 16:13 schrieb BH:
> This is a follow-up to problems we've had with on-screen display of
> fonts, where the spacing between words and cursor position was not
> calculated correctly due to ligatures, swooshes, or other font
> features. My guess is that the fix to that problem was to
This is a follow-up to problems we've had with on-screen display of
fonts, where the spacing between words and cursor position was not
calculated correctly due to ligatures, swooshes, or other font
features. My guess is that the fix to that problem was too general,
creating problems with monospaced
44 matches
Mail list logo
