macos.texi updated

macos.texi updated

[YAMAMOTO Mitsuharu]

I've updated man/macos.texi.  According to admin/FOR-RELEASE, it is
subject to proofreading by at least two persons before release.
Because this is my first time to edit Texinfo files, there may be some
"texi"cal and grammatical errors.  Corrections of such errors are
also appreciated.

BTW, there seems to be (sometimes loud) complaints about the use of
QuickDraw Text and XLFD for Carbon Emacs here and there.  So let me
say something about their backgrounds.

First, when I started the implementation of Central European and
Cyrillic display support by QuickDraw Text, I already knew that Steven
Tamm was working on ATSUI support and he was planning to add it to the
emacs-unicode-2 branch (actually I suggested that).  As I expected,
the implementation by QuickDraw Text was completed much earlier than
ATSUI support (that's natural because most of the parts could be
reused), and more importantly, displayable characters were increased
without losing stability.  If it had not been implemented, Carbon
Emacs could not display characters other than Mac Roman and CJK ones
still now without installing additional fonts.

Second, I think the evacuation from XLFD for Carbon Emacs is a bad
idea at least for Emacs 22 for the following reason.  In the Emacs 20
era, the face support code was window-system dependent: there were
xfaces.c and w32faces.c, and "Emacs on Aqua" also has nsfaces.m.  The
evacuation from XLFD for non-X11 ports might be meaningful for this
version.  However, the situation has changed in Emacs 21.  The face
support code has been much enhanced (35KB -> 209KB) and become
window-system independent: we only have xfaces.c and the Carbon port
as well as the W32 port is using it.  Since XLFD is used throughout
xfaces.c, introducing another representation for fonts in the Carbon
port not only increases reimplementation work, but also has danger of
losing some functionality that is already implemented in other
systems.  Of course, maintenance of code would also become more
difficult.  So the use of XLFD is not a detour for Carbon Emacs.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: macos.texi updated

[Steven Tamm]

To correctly use ATSUI, the way that fonts are cached and handled  
would have to change.  The cost of creating an ATSUStyle structure is  
ridiculously high and a new caching system would have to be added to  
maintain performance.  Furthermore, the calculations of line height  
and character width are more difficult to perform because of  
fractional character widths and the rounding errors was leaving  
artifacts all over the screen.  I was also trying to maintain  
backwards compatibility of old XLFDs, which I'm starting to think was  
unwise.  I've made two attempts at implementing an ATSUI based  
drawing engine, and I couldn't get it to work right.  It would  
probably be easier to graft on the parts of the Aqua (sic) port into  
the font/calculation/drawing portions than to convert from QDText to  
ATSU.  Unless someone has the time or the inclination to implement  
ATSU and pretty much rewrite the font calculation portions of macterm.

-Steven

On Sep 21, 2005, at 1:21 AM, YAMAMOTO Mitsuharu wrote:

> I've updated man/macos.texi.  According to admin/FOR-RELEASE, it is
> subject to proofreading by at least two persons before release.
> Because this is my first time to edit Texinfo files, there may be some
> "texi"cal and grammatical errors.  Corrections of such errors are
> also appreciated.
>
> BTW, there seems to be (sometimes loud) complaints about the use of
> QuickDraw Text and XLFD for Carbon Emacs here and there.  So let me
> say something about their backgrounds.
>
> First, when I started the implementation of Central European and
> Cyrillic display support by QuickDraw Text, I already knew that Steven
> Tamm was working on ATSUI support and he was planning to add it to the
> emacs-unicode-2 branch (actually I suggested that).  As I expected,
> the implementation by QuickDraw Text was completed much earlier than
> ATSUI support (that's natural because most of the parts could be
> reused), and more importantly, displayable characters were increased
> without losing stability.  If it had not been implemented, Carbon
> Emacs could not display characters other than Mac Roman and CJK ones
> still now without installing additional fonts.
>
> Second, I think the evacuation from XLFD for Carbon Emacs is a bad
> idea at least for Emacs 22 for the following reason.  In the Emacs 20
> era, the face support code was window-system dependent: there were
> xfaces.c and w32faces.c, and "Emacs on Aqua" also has nsfaces.m.  The
> evacuation from XLFD for non-X11 ports might be meaningful for this
> version.  However, the situation has changed in Emacs 21.  The face
> support code has been much enhanced (35KB -> 209KB) and become
> window-system independent: we only have xfaces.c and the Carbon port
> as well as the W32 port is using it.  Since XLFD is used throughout
> xfaces.c, introducing another representation for fonts in the Carbon
> port not only increases reimplementation work, but also has danger of
> losing some functionality that is already implemented in other
> systems.  Of course, maintenance of code would also become more
> difficult.  So the use of XLFD is not a detour for Carbon Emacs.
>
>                      YAMAMOTO Mitsuharu
>                 mituharu@math.s.chiba-u.ac.jp
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

Re: macos.texi updated

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 21 Sep 2005 23:12:43 -0700, Steven Tamm <steventamm@mac.com> said:

> It would probably be easier to graft on the parts of the Aqua (sic)
> port into the font/calculation/drawing portions than to convert from
> QDText to ATSU.  Unless someone has the time or the inclination to
> implement ATSU and pretty much rewrite the font calculation portions
> of macterm.

Maybe we need to consider whether there is a raison d'être of the
Carbon port or not (with respect to version 23, not 22) before making
further development effort for it.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: macos.texi updated

[Stefan Monnier]

> screen.  I was also trying to maintain  backwards compatibility of old
> XLFDs, which I'm starting to think was  unwise.  I've made two attempts at

Regarding this, I think it would be good for people working on Emacs.app,
w32, and Xft to get together and try to figure out what to do with the
font-naming problem.  It seems like the current use of XLFD may benefit from
an overhaul to adjust to the currently popular font technologies.


        Stefan

Re: macos.texi updated

[Adrian Robert]

> > screen.  I was also trying to maintain backwards compatibility of
> old > XLFDs, which I'm starting to think was unwise.  I've made two
> attempts at

> Regarding this, I think it would be good for people working on
> Emacs.app, w32, and Xft to get together and try to figure out what to
> do with the font-naming problem.  It seems like the current use of
> XLFD may benefit from an overhaul to adjust to the currently popular
> font technologies.

Even in X11, while XLFD is needed at the lowest level to interact with
the windowing system, is it really necessary to expose the user to it?
In the old days when emacs-X11 was first developed, X11 users were used
to specifying fonts in ...-*-*-*-*-... fashion.  Nowadays, most apps
shield them from this.  Thus, maybe it's reasonable to develop a new
emacs font specification style that's simpler, and use this even in the
face code until the lowest level where interaction w/the window system
takes place?

In most applications, users specify a font this way:

string:	family
float:	point size
bool:   bold
bool:   italic

One question is how to deal with systems that allow more user control.
For example, on OS X, some fonts have "semi-bold", "light", "condensed",
and other versions.  On X11, you can specify the DPI screen resolution
the font is optimized for, and font pixel size instead of point size.
The former situation could be handled using a fontspec like this:

("family-name" point-size (list-of-attributes))

Standard emacs faces would use just "bold" and "italic" as attributes,
but users could use others specific to their systems, which the window
system code would recognize.  Unrecognized attributes are ignored or
warned about.

This approach might also handle X11 things like DPI resolution.  For
example, one attribute might be "75-dpi".

Finally, a mechanism for ensuring some font family names are
cross-platform would be needed.  One approach here would be the
time-honored "map standard postscript names to system-specific ones":
each system would have a list of its equivalent families for "courier",
"times", and so on.  Another approach would be the web method of using
generic names like 'sans', 'serif', and 'fixed' in all emacs standard
faces.

Re: macos.texi updated

[YAMAMOTO Mitsuharu]

>>>>> On 25 Sep 2005 10:20:31 -0400, Adrian Robert <arobert@cogsci.ucsd.edu> said:

> Even in X11, while XLFD is needed at the lowest level to interact
> with the windowing system, is it really necessary to expose the user
> to it?  In the old days when emacs-X11 was first developed, X11
> users were used to specifying fonts in ...-*-*-*-*-... fashion.
> Nowadays, most apps shield them from this.  Thus, maybe it's
> reasonable to develop a new emacs font specification style that's
> simpler, and use this even in the face code until the lowest level
> where interaction w/the window system takes place?

I'm not against the introduction of a new font specification style,
but I think it is mainly for developers and power-users.  Emacs
already has a mechanism that enables users to specify fonts in a
simpler way at the face level.

  (set-face-attribute 'default nil :family "courier" :height 130)

And there is also an interactive one, i.e., M-x customize-face.

> Standard emacs faces would use just "bold" and "italic" as
> attributes, but users could use others specific to their systems,
> which the window system code would recognize.  Unrecognized
> attributes are ignored or warned about.

There are :width, :weight, and :slant attributes.  Currently they must
be selected from a fixed set, but not just "bold" and "italic" (9
levels for :width and :weight, and 5 variations for :slant).

> Finally, a mechanism for ensuring some font family names are
> cross-platform would be needed.  One approach here would be the
> time-honored "map standard postscript names to system-specific
> ones": each system would have a list of its equivalent families for
> "courier", "times", and so on.  Another approach would be the web
> method of using generic names like 'sans', 'serif', and 'fixed' in
> all emacs standard faces.

I think the variable `face-font-family-alternatives' would help to
provide such facility.  Currently, "courier" and "helv" are defined by
default.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: macos.texi updated

[Adrian Robert]

On Sep 28, 2005, at 4:30 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On 25 Sep 2005 10:20:31 -0400, Adrian Robert  
>>>>>> <arobert@cogsci.ucsd.edu> said:
>>>>>>
>
>
>> Even in X11, while XLFD is needed at the lowest level to interact
>> with the windowing system, is it really necessary to expose the user
>> to it?  In the old days when emacs-X11 was first developed, X11
>> users were used to specifying fonts in ...-*-*-*-*-... fashion.
>> Nowadays, most apps shield them from this.  Thus, maybe it's
>> reasonable to develop a new emacs font specification style that's
>> simpler, and use this even in the face code until the lowest level
>> where interaction w/the window system takes place?
>>
>
> I'm not against the introduction of a new font specification style,
> but I think it is mainly for developers and power-users.  Emacs
> already has a mechanism that enables users to specify fonts in a
> simpler way at the face level.

You're right..  But the population of "power users" in this case for  
whatever reason seems fairly large (just subjective impression), and  
the requirement to learn XLFD (to compose a fontset, or whatever  
else) and partake of the pleasures of asterisk-counting seems onerous.

In addition, I've been integrating the Cocoa port's font handling  
with xfaces.c, and can say it's onerous for developers.  All of these  
structures and functions concerned with creating, parsing, and  
storing the XLFD representation.  And you can't avoid using it in a  
port (at least, all of my attempts to work around it so far have  
failed), so each platform gets to join in the fun. Thus you find the  
various functions for faking (and unfaking) them under the two (now  
three) non-X platforms.

XLFD should be removed from non-window-system-specific code and  
replaced with a simple struct containing the same information.  In  
fact, given what's in font_info and common to "XFontStruct" on every  
platform right now, this would amount to adding a couple of fields,  
if that.  The only advantage of using a string representation I've  
seen so far is doing the regexp match in x_list_fonts.  But this is a  
false economy -- the extra code to do explicit field-by-field  
matching on a struct would be trivial, and far smaller than all of  
the XLFD translation and manipulation machinery now in place.  And it  
would be more efficient and reside completely in common, non-window- 
system-specific code.

Be that as it may, the people who write the code get to decide how it  
is, and I don't have the time / energy to try this rewrite now.  The  
Cocoa port will just live with it along with everyone else, though if  
it gets too ugly I might revisit this choice..

BTW, I don't want to sound too down on xfaces.c -- both it and the  
display interface code in general are vast improvements over emacs-20  
in terms of sharing common code and simplifying what the platform- 
specific part has to do.  (Not to mention the enhanced  
functionality.)  Kudos to Gerd Moellmann and everyone else responsible!

Re: macos.texi updated

[Richard M. Stallman]

    You're right..  But the population of "power users" in this case for  
    whatever reason seems fairly large (just subjective impression), and  
    the requirement to learn XLFD (to compose a fontset, or whatever  
    else) and partake of the pleasures of asterisk-counting seems onerous.

Is there a suitable font specification syntax in some other app that
we could imitate?  I don't think it is worth while for us to develop a
new one, and if it were unique to Emacs, it probably would not be very
useful.

    XLFD should be removed from non-window-system-specific code and  
    replaced with a simple struct containing the same information.

That is not a user interface proposal.  That is a proposal for a
simplification of internals of Emacs.  Maybe that would be a
simplification, maybe not.  In either case, I would rather we NOT
change this now.

But it has nothing  to do with the idea of presenting a different
_syntax_ for specifying a font, so I think it is just a distraction
from the issue we were talking about.

Re: macos.texi updated

[Adrian Robert]

On Oct 9, 2005, at 2:16 PM, Richard M. Stallman wrote:

>     You're right..  But the population of "power users" in this  
> case for
>     whatever reason seems fairly large (just subjective  
> impression), and
>     the requirement to learn XLFD (to compose a fontset, or whatever
>     else) and partake of the pleasures of asterisk-counting seems  
> onerous.
>
> Is there a suitable font specification syntax in some other app that
> we could imitate?  I don't think it is worth while for us to develop a
> new one, and if it were unique to Emacs, it probably would not be very
> useful.

I agree that introducing yet-another-syntax just to eliminate XLFD is  
debatable.  But I'm not sure whether a second syntax beyond the lisp  
syntax used for font specification within a face that Yamamoto-san  
posted earlier on this thread is needed at all.  (I guess I was  
trying to say, "drop XLFD, and if some functionality is lost, update  
the lisp syntax to fix it".)  But if a second syntax IS needed, CSS  
(Cascading Style Sheets) might be one source of an alternative that  
is likely to be both easier to work with and more familiar to most  
users than XLFD.  It's also structurally more similar to the existing  
lisp syntax than XLFD, because it uses a similar attribute+value  
scheme.  Compare:

(set-face-attribute 'default nil :family "courier" :height  
130 :weight 'bold :slant 'italic)

.default {
     font-family: courier;
     font-size: 13pt;
     font-weight: bold;
     font-style: italic;
}

Also, because the CSS format also supports attributes like foreground/ 
background color and borders, it could conceivably work for face  
specification beyond just the font.


>     XLFD should be removed from non-window-system-specific code and
>     replaced with a simple struct containing the same information.
>
> That is not a user interface proposal.  That is a proposal for a
> simplification of internals of Emacs.  Maybe that would be a
> simplification, maybe not.  In either case, I would rather we NOT
> change this now.
>
> But it has nothing  to do with the idea of presenting a different
> _syntax_ for specifying a font, so I think it is just a distraction
> from the issue we were talking about.

It is a separate issue (and I could/should have started a new thread  
I suppose), but it is related insofar as the exposure to the user of  
XLFD and the deep embedding of XLFD in the platform-independent face  
code are tied to one another.

In any case, I intended all of this discussion to apply to emacs 23,  
and to avoid unneeded distraction I'm happy to put it aside for now  
until 22 is out the door.

Re: macos.texi updated

[Richard M. Stallman]

      (I guess I was  
    trying to say, "drop XLFD, and if some functionality is lost, update  
    the lisp syntax to fix it".)

We don't need to change Emacs for that.  You should be able, already,
to do whatever you like in Emacs without using XLFD syntax.  What is there
that cannot be done except with XLFD syntax?  I think perhaps some
command line option uses it.  We could replace that option with
one that uses a different syntax, but what syntax should it be?

    .default {
	 font-family: courier;
	 font-size: 13pt;
	 font-weight: bold;
	 font-style: italic;
    }

I don't think that is useful in an Emacs context.
It is no easier to type, no more concise, than a list
of face attributes in Lisp syntax.  Where would we possibly
want to use it?

Not for the argument of a command-line option, for sure.

    > That is not a user interface proposal.  That is a proposal for a
    > simplification of internals of Emacs.  Maybe that would be a
    > simplification, maybe not.  In either case, I would rather we NOT
    > change this now.
    >
    > But it has nothing  to do with the idea of presenting a different
    > _syntax_ for specifying a font, so I think it is just a distraction
    > from the issue we were talking about.

    It is a separate issue (and I could/should have started a new thread  
    I suppose), but it is related insofar as the exposure to the user of  
    XLFD and the deep embedding of XLFD in the platform-independent face  
    code are tied to one another.

If someone wants to rewrite more of the internals of Emacs
to get rid of the internal use of XLFD syntax, that is fine with me.
Now is not the time to do it, of course.

Re: macos.texi updated

[David Reitter]

On 11 Oct 2005, at 15:44, Richard M. Stallman wrote:
>
>
>     .default {
>      font-family: courier;
>      font-size: 13pt;
>      font-weight: bold;
>      font-style: italic;
>     }
>
> I don't think that is useful in an Emacs context.
> It is no easier to type, no more concise, than a list
> of face attributes in Lisp syntax.  Where would we possibly
> want to use it?

Nowhere indeed. Normal lists will do the job, and they are better and  
easier to handle than the strings used now.

To do something to make the whole thing more usable, one can simply  
ensure that on each operating system the local standard font  
selection user interface is used. All systems offer some standard  
dialog to do that, and it would be a good idea if users can specify  
the lists with attributes in customization buffers as well, with the  
right widget.

Re: macos.texi updated

[Richard M. Stallman]

    To do something to make the whole thing more usable, one can simply  
    ensure that on each operating system the local standard font  
    selection user interface is used. All systems offer some standard  
    dialog to do that, and it would be a good idea if users can specify  
    the lists with attributes in customization buffers as well, with the  
    right widget.

I don't think we should be rigid about doing this--we need to consider
the suitability of each such interface for Emacs.  But in general
I agree that is a good direction to go in.

I don't know whether Xt offers any font-selection dialog.
Does it?

Re: macos.texi updated

[Adrian Robert]

[-- Attachment #1.1: Type: text/plain, Size: 3213 bytes --]


On Oct 11, 2005, at 10:44 AM, Richard M. Stallman wrote:

>       (I guess I was
>     trying to say, "drop XLFD, and if some functionality is lost,  
> update
>     the lisp syntax to fix it".)
>
> We don't need to change Emacs for that.  You should be able, already,
> to do whatever you like in Emacs without using XLFD syntax.  What  
> is there
> that cannot be done except with XLFD syntax?

Since I use Emacs on Aqua, which does not expose XLFD anywhere, I  
can't speak directly as a user.  But looking at the situation from  
the inside on the unicode-2 branch, it appears that there are several  
major places in the code that expect all of the information for  
specifying a font to be contained in a single string.  At the elisp- 
wielding-user-visible level this manifests in what you pass to and  
get back from x-list-fonts, as well as any font-setting functions,  
setting font as a frame parameter, etc...  I can't tell whether other  
platforms could use some other single-string-specifies-all format  
besides XLFD (not that this would be natural), or if other code in  
fontset.c and xfaces.c requires these names to be XLFD.  All I know  
is that in the Cocoa port, I'm having trouble getting the full font  
machinery working without putting all font info into string names.

In any case, both lisp code and user mailing list traffic for the Mac  
Carbon emacs contain numerous references to XLFD.  E.g.:

See for example:

http://search.gmane.org/?query=-apple- 
courier&email=&group=gmane.emacs.macintosh.osx&sort=relevance&DEFAULTOP= 
and&xP=apple-.&xFILTERS=Gemacs.macintosh.osx---A

http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/macemacsjp/carbon_font/ 
carbon-font.el

Anyway, I will drop this now due to an intense lack of interest from  
anyone else on this list ;), and come back when 22 is out and/or I  
have some code to show..


>   I think perhaps some
> command line option uses it.  We could replace that option with
> one that uses a different syntax, but what syntax should it be?
>
>     .default {
>      font-family: courier;
>      font-size: 13pt;
>      font-weight: bold;
>      font-style: italic;
>     }
>
> I don't think that is useful in an Emacs context.
> It is no easier to type, no more concise, than a list
> of face attributes in Lisp syntax.  Where would we possibly
> want to use it?

My point was that the XLFD is so concise and cryptic as to be a real  
hassle no matter what it's used for.  I really don't see any typing  
savings for something like

emacs -font '-*-courier-*-*-*--12-*-*-*-*-*-*-*'

or even

emacs -font '-*-courier-*-*-*--12-*'

vs.

emacs -font '{ font-family: courier font-size: 12pt }'

If you're not cutting/pasting the font, counting out how many  
asterisks you need and deciding where to put the '12' are far more  
time-consuming than punching out the few extra characters for CSS- 
style.  And if you are cutting/pasting, there's no difference,  
besides readability.

But given that things are as they are, I see no reason to add a new  
syntax either if it's not needed for lisp customization -- using XLFD  
on the command line seems fine since users on the non-X systems  
rarely use command-line invocation anyhow.


[-- Attachment #1.2: Type: text/html, Size: 4797 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: macos.texi updated

[Richard M. Stallman]

      At the elisp- 
    wielding-user-visible level this manifests in what you pass to and  
    get back from x-list-fonts, as well as any font-setting functions,  

Could you explain what "font-setting functions" means?
Could you name some "font-setting functions"?

    setting font as a frame parameter, etc...

That parameter basically exists for the sake of those who might
want to specify an XLFD font name.  It's not the normal way to
do things.

As for x-list-fonts, that uses XLFD because on X that was the
normal interface to use.  Is there a better way to do this now?

Re: macos.texi updated

[Adrian Robert]

On Oct 20, 2005, at 12:55 AM, Richard M. Stallman wrote:

>       At the elisp-
>     wielding-user-visible level this manifests in what you pass to and
>     get back from x-list-fonts, as well as any font-setting functions,
>
> Could you explain what "font-setting functions" means?
> Could you name some "font-setting functions"?

User-visible, that I know of:

set-frame-font
create-fontset-from-fontset-spec


>     setting font as a frame parameter, etc...
>
> That parameter basically exists for the sake of those who might
> want to specify an XLFD font name.  It's not the normal way to
> do things.

As far as I understand the code, and I could easily be wrong here, a 
default font specification in an X resource (or, on the GNUstep port, a 
user 'defaults database' value) makes it into the first emacs frame via 
a frame parameter.  (Faces then get defined off of this.)  In emacs-20, 
you could get away with just a font family and bold/italic spec here, 
since there was also a font size frame parameter, but this was removed 
in 22/23.

(Maybe in this case the answer is that emacs is trying to get away from 
other preferences persistence mechanisms besides .emacs?  But is .emacs 
read before the first frame is made?)


> As for x-list-fonts, that uses XLFD because on X that was the
> normal interface to use.  Is there a better way to do this now?

Right, but unfortunately x-list-fonts is not just used on X.  Ideally, 
there would be a "w-list-fonts" function that returns a list of lists 
specifying all the information in structured lisp form.  No lisp code 
calling this would need to muck about with window-system-specific 
string representations.  In practice, X was first and alone, so each 
port tended to just redefine its own version of x-list-fonts which 
translates its own font names into XLFD.  This is evil, but 
understandable given how things evolved.

Re: macos.texi updated

[Richard M. Stallman]

    set-frame-font

That is nearly obsolete--the modern and cleaner way to do this
is to customize the default font.

    create-fontset-from-fontset-spec

I don't know much about fontsets.  Perhaps we need a cleaner way
to specify them.

    (Maybe in this case the answer is that emacs is trying to get away from 
    other preferences persistence mechanisms besides .emacs?

Not particularly.  However, if you want to use X resources,
then you have to use XLFD.

							      But is .emacs 
    read before the first frame is made?)

Its specifications are applied to the first frame, I believe.

    Right, but unfortunately x-list-fonts is not just used on X.  Ideally, 
    there would be a "w-list-fonts" function that returns a list of lists 
    specifying all the information in structured lisp form.

That sounds like a good idea.  I will add it to etc/TODO.

Re: macos.texi updated

[Stefan Monnier]

>> I'm not against the introduction of a new font specification style,
>> but I think it is mainly for developers and power-users.  Emacs
>> already has a mechanism that enables users to specify fonts in a
>> simpler way at the face level.

> You're right..  But the population of "power users" in this case for
> whatever reason seems fairly large (just subjective impression), and the
> requirement to learn XLFD (to compose a fontset, or whatever else) and
> partake of the pleasures of asterisk-counting seems onerous.

This has nothing to do with power users.  It's simply that until Emacs-21,
XLFD was the standard way to specify fonts in Emacs, and that until recently
XLFD was the standard way to specify fonts in other X11 apps as well.
That's a lot of historical baggage.  Creating yet another syntax will not
reduce this baggage by one bit.

The fact is that there is a new syntax and people do use it, tho a lot of
people still use the old one.

> In addition, I've been integrating the Cocoa port's font handling with
> xfaces.c, and can say it's onerous for developers.

Yes, this part probably needs to be redesigned for Cocoa/OpenStep/xft/w32,
but it has nothing to do with the user-level interface.  The internal
interface should simply not use a syntax but data structures instead.


        Stefan

Re: macos.texi updated

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 07 Oct 2005 10:53:22 -0400, Adrian Robert <arobert@cogsci.ucsd.edu> said:

> In addition, I've been integrating the Cocoa port's font handling
> with xfaces.c, and can say it's onerous for developers.  All of
> these structures and functions concerned with creating, parsing, and
> storing the XLFD representation.  And you can't avoid using it in a
> port (at least, all of my attempts to work around it so far have
> failed), so each platform gets to join in the fun. Thus you find the
> various functions for faking (and unfaking) them under the two (now
> three) non-X platforms.

What we need to provide with respect to XLFD in the platform-dependent
part is x_list_fonts and x_load_font, whose main components are
emulations of XListFonts and XLoadQueryFont.  Not so many, I think.
Just out of curiosity, what part of them do you think is onerous?  Is
it missing or oversimplified in the Carbon port?

> The only advantage of using a string representation I've seen so far
> is doing the regexp match in x_list_fonts.  But this is a false
> economy -- the extra code to do explicit field-by-field matching on
> a struct would be trivial, and far smaller than all of the XLFD
> translation and manipulation machinery now in place.

The Carbon port has been used the regexp match for XLFD pattern match,
but it turned out that almost a half of the startup time was used for
that.  So, recently it was changed to use more straightforward pattern
matching.  Yes, it might also be a false economy, but it was much
simpler and safer than modifying xfaces.c/fontset.c.  Of course, the
situation might change in Emacs 23.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: macos.texi updated

[Adrian Robert]

On Oct 11, 2005, at 4:01 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Fri, 07 Oct 2005 10:53:22 -0400, Adrian Robert  
>>>>>> <arobert@cogsci.ucsd.edu> said:
>>>>>>
>
>
>> In addition, I've been integrating the Cocoa port's font handling
>> with xfaces.c, and can say it's onerous for developers.  All of
>> these structures and functions concerned with creating, parsing, and
>> storing the XLFD representation.  And you can't avoid using it in a
>> port (at least, all of my attempts to work around it so far have
>> failed), so each platform gets to join in the fun. Thus you find the
>> various functions for faking (and unfaking) them under the two (now
>> three) non-X platforms.
>>
>
> What we need to provide with respect to XLFD in the platform-dependent
> part is x_list_fonts and x_load_font, whose main components are
> emulations of XListFonts and XLoadQueryFont.  Not so many, I think.
> Just out of curiosity, what part of them do you think is onerous?  Is
> it missing or oversimplified in the Carbon port?

This is subjective.. it works out to about 2-3% of the ports on the  
unicode 2 branch, but that is a lot:

In Carbon (macterm.c), my brief survey found "only" 500 lines  
concerned more or less directly with XLFD compatibility.

In W32 (w32fns.c), I found around 1000 lines.

Obviously the approach makes a difference here, and I'm hoping the  
Cocoa port can be less, as it has around 600 lines for all of font  
management right now ex-XLFD, and doubling that would be  
depressing. ;-)  Bottom line, 500 lines seems a lot when this is over  
and above both the code doing the main business of x_list_fonts and  
the code filling in all of the XFontStruct and font_info when loading  
fonts.  Also, xfaces.c itself suffers; if the XLFD stuff were  
separated out to "xfaces.c" (and "wfaces.c" was made for the  
windowing-general part), I strongly suspect the code would be easier  
to understand and maintain.

Re: macos.texi updated

[Jesper Harder]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> I've updated man/macos.texi.  According to admin/FOR-RELEASE, it is
> subject to proofreading by at least two persons before release.
> Because this is my first time to edit Texinfo files, there may be some
> "texi"cal and grammatical errors.  Corrections of such errors are
> also appreciated.

Hi,

I think one thing that would be very helpful is to give intructions on
how to set up fonts for comprehensive coverage of unicode (if it's even
possible).

It's clear from the text that the OS bundled fonts won't do. So, what
do you do instead?  Can you use GNU Intlfonts?  How?

Re: macos.texi updated

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 22 Sep 2005 22:42:41 +0200, Jesper Harder <jesper.harder@gmail.com> said:

> I think one thing that would be very helpful is to give intructions
> on how to set up fonts for comprehensive coverage of unicode (if
> it's even possible).

Sorry, I'm not sure if it is possible or not.  Some of *-iso8859-* are
covered by converted GNU intlfonts, but not for mule-unicode-*
charsets.

> It's clear from the text that the OS bundled fonts won't do. So,
> what do you do instead?  Can you use GNU Intlfonts?  How?

Unfortunately, the URL

  ftp://mac-emacs.sourceforge.net/pub/mac-emacs/GNU-fonts.smi.bin

mentioned in mac/INSTALL is not accessible as of today.  Does anyone
know whether it is temporary failure or permanent one?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: macos.texi updated

[Cheng Gao]

>>>>> "YAMAMOTO" == YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

    YAMAMOTO> Unfortunately, the URL
    YAMAMOTO> ftp://mac-emacs.sourceforge.net/pub/mac-emacs/GNU-fonts.smi.bin

    YAMAMOTO> mentioned in mac/INSTALL is not accessible as of today.  Does anyone
    YAMAMOTO> know whether it is temporary failure or permanent one?
Yaced project hosts this package. You can get it at
https://sourceforge.net/project/showfiles.php?group_id=132323

Re: macos.texi updated

[Jesper Harder]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>> On Thu, 22 Sep 2005 22:42:41 +0200, Jesper Harder <jesper.harder@gmail.com> said:
>
>> I think one thing that would be very helpful is to give intructions
>> on how to set up fonts for comprehensive coverage of unicode (if
>> it's even possible).
>
> Sorry, I'm not sure if it is possible or not.  Some of *-iso8859-* are
> covered by converted GNU intlfonts, but not for mule-unicode-*
> charsets.

Hmm, no, unfortunately GNU Intlfonts doesn't help at all on OS X.  Its
coverage is even worse than when using only the OS-bundled fonts. Too
bad :-(

Re: macos.texi updated

[Richard M. Stallman]

    I've updated man/macos.texi.

Thank you.

				  According to admin/FOR-RELEASE, it is
    subject to proofreading by at least two persons before release.

It would be a good idea for two people to check your writing.
I see that nobody is listed so far as having checked it.

We have made a lot of progress lately towards the release,
but one area which has made little progress lately is the checking
of the manual.  Would people please work on this?