[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: char-displayable-p issue
Re: char-displayable-p issue
Wed, 22 Oct 2003 12:09:50 -0700 (PDT)
--- Michael Mauger <address@hidden> wrote:
> --- Kenichi Handa <address@hidden> wrote:
> > --- Michael Mauger <address@hidden> wrote:
> > > I can't reproduce that bug. When I turned on ruler-mode, I
> > > see both characters in the ruler head. Isn't it a bug
> > > specific to Windows?
> > > Yes, it seems the problem is specific to Windows. Work
> > > well on my GNU/Linux box.
> > > The problem seems
> > > to be that the wildcard pattern generated in
> > > `char-displayable-p' is not matching multiple hyphen
> > > separated portions of the font name. That is,
> > > '-*-*-iso8859-1' doesn't match any fonts while
> > > '-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1' does.
> > How about
> > '-*-iso8859-1'? Doest it match all iso8859-1 fonts? If so,
> > instead of just changing "-*-" to "-*-*-*-*-*-*-*-*-*-*-*-",
> > generating the most compact font-pattern (i.e. no succeeding
> > wildcards) will solve the problem without making Windows
> > version slow.
> > Even if that doesn't work, your patch is not enough. I
> > think we must change the length of "-*-..-*-" according to
> > the form of car of font-pattern ("FOUNDRY-FAMILY",
> > "*FAMILY", or "FOUNDRY*")
> I tried '-*-iso8859-1' and it also failed. The problem appears to be
> in the Windows implementation of x-list-fonts (w32_list_fonts in
> src/w32fns.c). The wildcarding is obviously not working as intended.
Okay, I think I've isolated the font matching problem down to its
source. The issue arises in the routine `x_to_w32_font' in
src/w32fns.c. This routine translates a XLFD string into a Windows
LOGFONT structure. The problem is that this routine only handles the
[special case generated by font_list_1 invoked by try_font_list]
Thus, the strings '-*-iso8859-1' and '-*-*-iso8859-1' are not being
I see several possible solutions to this specific (char-displayable-p
failing) problem (somewhat in the order of complexity):
1. Alter `char-displayable-p' to generate a string of the form
'-FOUNDRY-FAMILY-*-REGISTRY-ENCODING' in all cases. Requires
parsing the car of the result from fontset-font to ensure
sufficient hyphens/wildcards have been inserted for it to be
properly parsed on Windows.
2. Same as above but conditional on (eq window-system 'w32).
3. Modify `x_to_w32_font' to handle the forms:
The code in this routine is a little fragile. There are many
special cases handled implicitly without explicit acknowledgement
that they are there.
4. Rewrite the parser in `x_to_w32_font' to more properly handle
wildcards. I'm not sure that this can even be done and it is
probably unnecessary given the limited number of font patterns
likely to be encountered.
I see option 3 as the ideal, and I will start to work on it.
One other issue: Kenichi Handa said that the car of font-pattern
could be one of "FOUNDRY-FAMILY", "*FAMILY", or "FOUNDRY*", in
addition to nil. My solution would not handle the "*FAMILY" form
unless it is really sent as "*-FAMILY". The Windows code does
not handle partial wildcards in the font pattern. Will these forms
ever be generated by the Windows code?
If the car of the font-pattern does not have the hyphens with the
wildcard then we need to handle these cases specially. I would
propose handling them in `char-displayable-p' because their meaning
is clear at that point. Trying to accommodate the partial wildcards
in `x_to_w32_font' may break other usages.
The internals of Emacs and Windows are by no means my strength, so
if you have comments please send them along. Thanks.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software