Re: font-backend branch

[Kenichi Handa]

In article <address@hidden>, Jason Rumney <address@hidden> writes:

> At which point is the build failing now?

The same point as I wrote before.

> It might simplify things to 
> copy your lisp directory from another plaform to avoid the need to 
> bootstrap, as that is where most subtle problems with Windows build 
> environments come up.

Ah, that's a good idea.  I've just done it, and now I have
running Emacs on Windows.

> I think I have fixed the font selection problem, by adding code to copy 
> the entries from font_entity to the new font_object in 
> w32font_open_internal.

Ah, thank you for finding out that.  I have forgotten to do
that when I modified w32font.c.  :-(

[...]
> > After that, there is always a garbage character following the boxes 
> > that indicate a missing font. If the cursor is anywhere on the line, 
> > then the garbage character changes, at the same rate the cursor is 
> > blinking at.

> This is fixed by your change to w32term.c.

That's good.

> Now only the initial display 
> corruption is a problem, so I will debug that and see if I can 
> differentiate between errors that mean the font cannot use glyph codes, 
> and other errors that only apply to specific characters, which we could 
> indicate by treating that character as missing in the font.

Thank you.

By the way, could you make the `open' function of each
font-driver to set XLFD name in
font->props[FONT_NAME_INDEX].  Currently only the family
name is set there, but it seems that some people has a code
that expects XLFD name in the return value of
(frame-parameter nil 'font).

---
Kenichi Handa
address@hidden