[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: char-displayable-p issue
From: |
Michael Mauger |
Subject: |
Re: char-displayable-p issue |
Date: |
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
following formats:
[fully qualified]
-FOUNDRY-FAMILY-WEIGHT-SLANT-WIDTH-STYLE-PIXELSIZE-POINTSIZE-RESX-RESY
-SPACING-AVGWIDTH-REGISTRY-ENCODING
[special case generated by font_list_1 invoked by try_font_list]
-FOUNDRY-FAMILY-*-REGISTRY-ENCODING
[Windows-specific formats]
FAMILY:PIXELHEIGHT:PIXELWIDTH:WEIGHT
FAMILY:PIXELHEIGHT:PIXELWIDTH
FAMILY:PIXELHEIGHT
FAMILY
Thus, the strings '-*-iso8859-1' and '-*-*-iso8859-1' are not being
parsed properly.
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:
-FOUNDRY-*-REGISTRY-ENCODING
-*-REGISTRY-ENCODING
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.
-- Michael
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com