Rendering of synthesized bold/italic

Folks -

I was looking over the pending bugs for 3.9 and this one bothers me
greatly: http://bugs.impara.de/view.php?id=3604 . Since none of the
rendering code has changed, I have no idea what could possibly cause
this regression between 3.8 and 3.9. My best guess is that somehow the
fonts themselves got modified but how and where might this have
happened? Perhaps an accident in the uploaded image? (I didn't update
from 3.8 but used a downloaded 3.9 to see if the problem is still there)

Any ideas anyone? Personally, this is a show-stopper for me.

Cheers,
   - Andreas

 "Andreas Raab" <[hidden email]> wrote:



> Folks -
Thank you for bringing my attention to this problem.
>
> I was looking over the pending bugs for 3.9 and this one bothers me
> greatly: http://bugs.impara.de/view.php?id=3604 . Since none of the
> rendering code has changed, I have no idea what could possibly cause
> this regression between 3.8 and 3.9. My best guess is that somehow the
> fonts themselves got modified but how and where might this have
> happened?

Perhaps. To create bold fonts we have to ensure a 1-pixel interspace
between glyphs in the glyphs form. Perhaps we had that earlier and
lost it again when  fonts were moved around between StrikeFonts and
StrikeFontSets.

> Perhaps an accident in the uploaded image? (I didn't update
> from 3.8 but used a downloaded 3.9 to see if the problem is still there)
>
> Any ideas anyone? Personally, this is a show-stopper for me.

In earlier times we used StrikeFonts, now we use StrikeFontSets.
There is in fact a minor difference in the code of these classes:
In StrikeFont, we use the method  ensureCleanBold  that adds the
1-pixel interspace when it is not already present. In StrikeFontSet
we do not use that method.

Attached you find a proposal for a preliminary fix. It betters the
situation, but there is still an imperfaction: We do not properly
display the overhang of large italics. I think I remember that
I fixed that for StrikeFonts some years ago and I will check my
records to find the fix. It was somewhere in CharacterScanner
(That calss underwent a lot of changes in connection with
internationalization support)

I will update the Mantis record as soon as I have a solution for the
overhang problem. The attached file should only give you a hint
where the problem is.

> Cheers,
>    - Boris
>
PS: I found that MVC is so very damages thatwe should
perhaps drop it altogether. What is the opinion of the
community about that question? (Personally I am a lover
of the old MVC, but I use it in 3.7)

> PS: I found that MVC is so very damages thatwe should
> perhaps drop it altogether. What is the opinion of the
> community about that question? (Personally I am a lover
> of the old MVC, but I use it in 3.7)

I would drop it.

On 9-Jul-06, at 2:49 AM, stéphane ducasse wrote:

>> PS: I found that MVC is so very damages thatwe should
>> perhaps drop it altogether. What is the opinion of the
>> community about that question? (Personally I am a lover
>> of the old MVC, but I use it in 3.7)
>
> I would drop it.
Reluctantly, I would have to agree. If nothing else it might persuade  
some enthusiastic person(s) with some time to look at morphic and  
improve its performance.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The generation of random numbers is too important to be left to chance.

Am 09.07.2006 um 09:14 schrieb Boris Gaertner:

That might be an artifact of the "FixInvisible" package (http://
source.impara.de/underscore.html). It replaces all non-whitespace but  
blank glyphs with a hollow square. IIRC it does not leave a "1-pixel  
interspace", didn't know it had to.

- Bert -

Is there a way to undo this change? I'd rather have unprintable
characters be invisible than printable characters be badly distorted.

Cheers,
   - Andreas

Bert Freudenberg wrote: