--- Jason Rumney wrote: > Michael Mauger writes: > > > 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. > > > I see option 3 as the ideal, and I will start to work on it. > > Thank you. I have tweaked that bit of code many times now to fix > bugs like this, it could do with a fresh set of eyes. Please document > any implicit special cases that you find. > I ended up having to rewrite the parser. (See diff attached). The XLFD string is broken into segments and the last wildcard prior to the last segment is expanded into multiple wildcards to fill out the full spec. This is not perfect but seems to address the most common usages. It does correct the bug that raised this thread. However, it does expose some bugs deeper in the font selection process that I have not been able to isolate yet. For example, '-*-*-iso8859-1' returns all the Latin-1 fonts as does '-*-*-*-*-*-*-iso8859-1' (6 segments prior to the charset), but '-*-*-*-*-*-iso8859-1' (5 segments prior to the charset) returns none. The function `x_to_w32_font' returns the same LOGFONT structure in each case. The issues appear to be in interpreting portions of the XLFD string later during the font enumeration process. I haven't been able to decypher that code as of yet. I've been using the following elisp code to test `x-list-fonts': (let ((i 0) (p "") l) (while (< i 14) (setq i (+ i 1) p (concat p "-*") l (length (x-list-fonts (concat p "-iso8859-1")))) (princ (concat (number-to-string i) "=>" (number-to-string l) " ")))) For values of `i' of 5, 8, and 9, no matches are made (also for values of 12 and 13, but that is because the the pattern is too long). > > 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. > > I recently changed the font selection code in the emacs-unicode-2 > branch to fix the same problem in charset and encoding fields. The > approach I took is to treat partial wildcards as full wildcards in > x_to_w32_charset, and to do more thorough comparisons in > enum_font_cb2. > I don't want to attempt this until I understand the font emun process better. > > Trying to accommodate the partial wildcards in `x_to_w32_font' may > > break other usages. > > That is my experience with trying to do anything in x_to_w32_font. It > is not an easy piece of code to get "right". That is why I have not > rushed into merging the changes I made to get emacs-unicode-2 to work > back into HEAD. > Jason, you're probably the best one to evaluate these changes and their impact on the future unicode changes. -- Michael __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com