* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" @ 2014-05-11 1:57 Drew Adams 2014-05-11 2:07 ` Drew Adams 2014-05-11 4:40 ` Eli Zaretskii 0 siblings, 2 replies; 8+ messages in thread From: Drew Adams @ 2014-05-11 1:57 UTC (permalink / raw) To: 17457 Subject line says it all. No problem in Emacs 24 or prior releases: M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono") ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1" "Arial-12.0" 20 23 0 0 19] In this build, however, I get this: Debugger entered--Lisp error: (error "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono") font-info("-outline-Lucida Console-normal-normal-normal-mono") In GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-04-29 on ODIEONE Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1 -Ic:/Devel/emacs/include'' ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" 2014-05-11 1:57 bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" Drew Adams @ 2014-05-11 2:07 ` Drew Adams 2014-05-11 4:40 ` Eli Zaretskii 1 sibling, 0 replies; 8+ messages in thread From: Drew Adams @ 2014-05-11 2:07 UTC (permalink / raw) To: 17457 Works with all builds through 2013-06-17, this build: In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-06-17 on ODIEONE Bzr revision: 113024 eliz@gnu.org-20130617163040-8hmzci370q4argze Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib CPPFLAGS=-Ic:/Devel/emacs/include' Regression introduced before this (broken) build: In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-06-18 on LEG570 Bzr revision: 113050 handa@gnu.org-20130618145521-fvpc5viqtc85j4j4 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3' CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include'' ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" 2014-05-11 1:57 bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" Drew Adams 2014-05-11 2:07 ` Drew Adams @ 2014-05-11 4:40 ` Eli Zaretskii 1 sibling, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2014-05-11 4:40 UTC (permalink / raw) To: Drew Adams; +Cc: 17457 > Date: Sat, 10 May 2014 18:57:50 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > > Subject line says it all. No problem in Emacs 24 or prior releases: > > M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono") > ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1" > "Arial-12.0" 20 23 0 0 19] What do you get in prior releases, and why do you think that output is correct? This is in "emacs -Q", btw, right? ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <<a68b8275-2f8b-4e80-8e34-5905d809da11@default>]
[parent not found: <<83eh01udux.fsf@gnu.org>]
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" [not found] ` <<83eh01udux.fsf@gnu.org> @ 2014-05-11 5:23 ` Drew Adams 2014-05-11 16:03 ` Eli Zaretskii [not found] ` <<cadd8cdd-0fd8-454a-9f82-901c41e19423@default> 1 sibling, 1 reply; 8+ messages in thread From: Drew Adams @ 2014-05-11 5:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17457 > > Subject line says it all. No problem in Emacs 24 or prior releases: > > > > M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono") > > ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1" > > "Arial-12.0" 20 23 0 0 19] > > What do you get in prior releases, and why do you think that output is > correct? In prior releases (Emacs 23 through 24.3) I get what I showed above for prior releases. Why should I think it is not correct? Why should Emacs suddenly start treating it as invalid? OK, yes, it seems weird that the font info returned seems to be for a different font in this case! I'll grant you that perhaps there is an Emacs bug there to be fixed. But at least in previous versions Emacs did not claim the font was invalid. I don't see why it would be invalid (either the Lucida font or the Arial font that Emacs apparently used to think it was looking at). Lucida Console is in fact the font currently in use in the frame where I ask for the value (when I test with my setup, which uses that font by default). This is what the frame parameter `font' value is: "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1" Where did I get the value of the arg I pass to `font-info'? From here: (append fontset-lst (x-list-fonts "*")), where FONTSET-LST is this; (let ((fontset-lst (fontset-list))) (setq fontset-lst (delete "-*-*-*-*-*-*-*-*-*-*-*-*-fontset-default" fontset-lst)) ...) I map `font-info' over the above list composed of `fontset-list' fonts and `x-list-fonts' fonts. I have been doing so for a long time. I really hadn't noticed until now that for the Lucida font `font-info' apparently returned information for a different font (Arial). But in general it has worked well. The info I use from `font-info' is just this: (format "pixelsize: %s, pixelheight: %s, offset: %s, compose: %s, ascent: %s" (aref font-info iii) (aref font-info (+ iii 1)) (aref font-info (+ iii 2)) (aref font-info (+ iii 3)) (aref font-info (+ iii 4))) And that seemed to be OK generally, but I admit that I didn't check that it is always using the right font. What I can say is that the values for those parts(in previous versions) are different for different fonts. And for a font that is not yet loaded I do get a nil value returned from `font-info'. Now, with the builds since 2013-06-18, I get an invalid-font error instead. > This is in "emacs -Q", btw, right? Yes. And no - it makes no difference: Both with my setup and with emacs -Q I get the same behavior, both for previous versions (where Emacs raises no error and returns the vector above) and for the reported regression builds. `font-info' is supposed to return either font info or nil if the font is not yet loaded. In my case the Lucida font is loaded (even for emacs -Q). ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" 2014-05-11 5:23 ` Drew Adams @ 2014-05-11 16:03 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2014-05-11 16:03 UTC (permalink / raw) To: Drew Adams; +Cc: 17457 > Date: Sat, 10 May 2014 22:23:41 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 17457@debbugs.gnu.org > > > > Subject line says it all. No problem in Emacs 24 or prior releases: > > > > > > M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono") > > > ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1" > > > "Arial-12.0" 20 23 0 0 19] > > > > What do you get in prior releases, and why do you think that output is > > correct? > > In prior releases (Emacs 23 through 24.3) I get what I showed above > for prior releases. Why should I think it is not correct? Why > should Emacs suddenly start treating it as invalid? Because it indeed _is_ invalid, see below. > OK, yes, it seems weird that the font info returned seems to be for > a different font in this case! I'll grant you that perhaps there is > an Emacs bug there to be fixed. Yes, there was a bug, and it has been fixed in the current code. That's why you started to get that error. > But at least in previous versions Emacs did not claim the font was > invalid. I don't see why it would be invalid (either the Lucida > font or the Arial font that Emacs apparently used to think it was > looking at). There's nothing wrong with the fonts, it's just that you are using an invalid specification of a font. > Where did I get the value of the arg I pass to `font-info'? > >From here: (append fontset-lst (x-list-fonts "*")), where > FONTSET-LST is this; > > (let ((fontset-lst (fontset-list))) > (setq fontset-lst > (delete "-*-*-*-*-*-*-*-*-*-*-*-*-fontset-default" > fontset-lst)) > ...) But the above doesn't yield "-outline-Lucida Console-normal-normal-normal-mono", it yields this: "-outline-Lucida Console-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1" And if I use this longer string, there's no problem: M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1") RET => ["-outline-Lucida Console-normal-normal-normal-mono-16-*-*-*-c-*-iso10646-1" "Lucida Console-12.0" 16 16 0 0 13] Likewise with this more loose spec: "-outline-Lucida Console-normal-normal-normal-mono-*-*-*-*-*-*-*" > I map `font-info' over the above list composed of `fontset-list' > fonts and `x-list-fonts' fonts. I have been doing so for a > long time. There must be some other factor at work here, because I don't understand how you get your truncated spec. Font specifications that start with a dash "-" are XLFD specs, and they must be built according to certain rules to be valid. (See the node "Fonts" in the User manual for some details.) Your string starts with a dash, which means it's an XLFD spec, but it has too few components (the parts between dashes) for an XLFD spec, so Emacs rejects it as invalid. Previously, it didn't detect the problem, and would return information about some semi-random font, whose particulars depend on which fonts are installed on your system. E.g., on one of my systems I get Arial, like you, but on another I get this: ["-outline-STIX-normal-normal-normal-mono-16-*-*-*-p-*-iso8859-1" "STIX-12.0" 16 24 0 0 16] > I really hadn't noticed until now that for the Lucida font `font-info' > apparently returned information for a different font (Arial). But in > general it has worked well. The info I use from `font-info' is just this: > > (format > "pixelsize: %s, pixelheight: %s, offset: %s, compose: %s, ascent: %s" > (aref font-info iii) (aref font-info (+ iii 1)) > (aref font-info (+ iii 2)) (aref font-info (+ iii 3)) > (aref font-info (+ iii 4))) This info will be incorrect if you get it for the wrong font. The pixelsize and pixelheight parameters are different, for starters. > `font-info' is supposed to return either font info or nil if the > font is not yet loaded. I don't see a problem with a function that signals an error when passed invalid input, even though that fact is not stated in the documentation: we rarely state that in other cases. For example: M-: (string-width 1) RET => error ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <<cadd8cdd-0fd8-454a-9f82-901c41e19423@default>]
[parent not found: <<83a9aouwtj.fsf@gnu.org>]
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" [not found] ` <<83a9aouwtj.fsf@gnu.org> @ 2014-05-11 17:19 ` Drew Adams 2014-05-11 17:41 ` Eli Zaretskii [not found] ` <<c873b85c-4ea9-462f-b2a4-4761a218b2e1@default> 1 sibling, 1 reply; 8+ messages in thread From: Drew Adams @ 2014-05-11 17:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17457 > There must be some other factor at work here, because I don't > understand how you get your truncated spec. Yes, sorry. This is what I was doing, with var FONT as input: (save-match-data (let ((xlfd-regexp "\\`\\(-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\)\ -[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\'")) (or (not (string-match xlfd-regexp font)) (setq font (replace-match "\\1" nil nil font))))) I truncated it because I am not interested in anything except the first 6 fields of the XLFD string. And previously, or so I thought, `font-info' worked OK with such a truncated font spec. (And - see below - I thought that allowed me to get font info for some fonts that otherwise did not give info. I did not realize that `font-info' was in fact giving me incorrect info for those fonts.) I then filtered out the case of a literal (string= font "-*-*-*-*-*-*"), then passed the FONT to `font-info'. I have fixed my code now so that the main feature works. But `font-info' still complains about some of the fonts I have. I've wrapped the `font-info' call in an `ignore-errors' to ignore that, but this means that I cannot get font info for those few fonts. So be it. FYI, here are some problematic fonts. It is no doubt the addition of extra fields that makes them invalid. -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1 -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1 -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1 -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1 -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1 -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1 -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-gb2312.1980-0 -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1 -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso8859-1 All of those fonts seem to work OK outside of Emacs. But yes, Emacs now rejects them - this raises the same invalid font error: M-x set-frame-font -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 Is Emacs doing the right thing here and other applications (e.g. Outlook) are wrong? If you see no bug wrt this, OK. In any case, I will close the current bug. Thanks for taking a look. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" 2014-05-11 17:19 ` Drew Adams @ 2014-05-11 17:41 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2014-05-11 17:41 UTC (permalink / raw) To: Drew Adams, Kenichi Handa; +Cc: 17457 > Date: Sun, 11 May 2014 10:19:58 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 17457@debbugs.gnu.org > > > There must be some other factor at work here, because I don't > > understand how you get your truncated spec. > > Yes, sorry. This is what I was doing, with var FONT as input: > > (save-match-data > (let ((xlfd-regexp "\\`\\(-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\)\ > -[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\'")) > (or (not (string-match xlfd-regexp font)) > (setq font (replace-match "\\1" nil nil font))))) > > I truncated it because I am not interested in anything except the > first 6 fields of the XLFD string. The right way is to replace the other fields with "*", not chop them off. > I have fixed my code now so that the main feature works. But `font-info' > still complains about some of the fonts I have. I've wrapped the > `font-info' call in an `ignore-errors' to ignore that, but this means that > I cannot get font info for those few fonts. So be it. > > FYI, here are some problematic fonts. It is no doubt the addition of > extra fields that makes them invalid. > > -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 > -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1 > -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1 > -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 > -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1 > -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1 > -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0 > -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1 > -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1 > -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-gb2312.1980-0 > -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1 > -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso8859-1 Yes, I think the problem is in that "-ExtB", which I think is part of the font name, but Emacs's XLFD parser thinks it is a separate field. Perhaps Handa-san, or someone else who knows more about fonts, could tell how to handle these font names correctly. It looks like a bug to me, FWIW. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <<c873b85c-4ea9-462f-b2a4-4761a218b2e1@default>]
[parent not found: <<834n0wus9k.fsf@gnu.org>]
* bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" [not found] ` <<834n0wus9k.fsf@gnu.org> @ 2014-05-11 19:23 ` Drew Adams 0 siblings, 0 replies; 8+ messages in thread From: Drew Adams @ 2014-05-11 19:23 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams, Kenichi Handa; +Cc: 17457 > > I truncated it because I am not interested in anything except the > > first 6 fields of the XLFD string. > > The right way is to replace the other fields with "*", not chop them > off. I almost added, and will add now, that I think perhaps the reason I did that before passing the font arg to `font-info', was mainly to allow handling of the problematic fonts. I did not realize, however, that they were anyway not being handled correctly that way. They were tolerated, but the returned info was not relevant. > Yes, I think the problem is in that "-ExtB", which I think is part of > the font name, but Emacs's XLFD parser thinks it is a separate field. > Perhaps Handa-san, or someone else who knows more about fonts, could > tell how to handle these font names correctly. It looks like a bug to > me, FWIW. I thought of that, but I don't know how the name should be parsed, to determine that the name field has ended. Perhaps the following field has only a fixed number of possibilities. But then there is (IIRC) the possibility that fields can be missing. IOW, is it perhaps problematic to parse names that contain hyphens? I closed the bug. If appropriate, feel free to open it based on the possibility of a parsing problem. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-05-11 19:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-05-11 1:57 bug#17457: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono" Drew Adams 2014-05-11 2:07 ` Drew Adams 2014-05-11 4:40 ` Eli Zaretskii [not found] <<a68b8275-2f8b-4e80-8e34-5905d809da11@default> [not found] ` <<83eh01udux.fsf@gnu.org> 2014-05-11 5:23 ` Drew Adams 2014-05-11 16:03 ` Eli Zaretskii [not found] ` <<cadd8cdd-0fd8-454a-9f82-901c41e19423@default> [not found] ` <<83a9aouwtj.fsf@gnu.org> 2014-05-11 17:19 ` Drew Adams 2014-05-11 17:41 ` Eli Zaretskii [not found] ` <<c873b85c-4ea9-462f-b2a4-4761a218b2e1@default> [not found] ` <<834n0wus9k.fsf@gnu.org> 2014-05-11 19:23 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).