11:01 p.m.
I am cleaning up the redisplay code to implement printing in Windows.
This patch uses system-provided underline and strike out fonts.
Struck out and underlined fonts are now supported on widgets, for no
reason, because nobody wants them to look like that anyway! :)
The idea is that each font instance has up to four HFONTs associated
with it, called variants, for all under/struck combinations. Only one
is created initially, with the rest being created and cached in
instance data as they are needed, during redisplay.
This patch accumulates Windows specific changes, winsys-independent
part is under way.
An RFC. There are now 2 ways to create an underlined face. One is to
specify font modifier 'underline', like "Courier
New:Regular:9:underline".
The other way is to create a non-underlined font, and set underline-p
property of the *face* to t. These faces won't be the same. Even worse,
the first face line height will be 1 greater than the second!
(Although, with 10pt size, they are same. Thanks Bill!).
Should the modifiers 'underline' and 'strikethru' go away from the
fonts?
Big K
2000-01-17 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
* faces.h (FACE_STRIKETHRU_P): Added.
* glyphs-msw.c (mswindows_widget_hfont): Implemented, to take care
of font variants.
* redisplay-msw.c (mswindows_apply_face_effects): Deleted.
(mswindows_set_dc_font): New function, aware of font variants,
separated from mswindows_update_dc.
* objects-msw.h (struct mswindows_font_instance_data): Added
definition.
* objects-msw.c (mswindows_finalize_font_instance): Delete all
cached fonts and the data structure.
(mswindows_initialize_font_instance): Added creation of font data
structure.
(mswindows_print_font_instance): Print at least something.
(mswindows_create_font_variant): Implemented.
(mswindows_get_hfont): Implemented.
4:33 a.m.
The hope was the opposite -- eliminate the "font" property and separate out
each individual property of it to a separate face property. The problem was,
there was disagreement over how to design this. Kyle wants to have a "font"
property containing a list of all the actual font properties. I think it's
arbitrary to distinguish between font and other properties, and that all
properties should be equal at the face level.
Kirill 'Big K' Katsnelson wrote:
I am cleaning up the redisplay code to implement printing in
Windows.
This patch uses system-provided underline and strike out fonts.
Struck out and underlined fonts are now supported on widgets, for no
reason, because nobody wants them to look like that anyway! :)
The idea is that each font instance has up to four HFONTs associated
with it, called variants, for all under/struck combinations. Only one
is created initially, with the rest being created and cached in
instance data as they are needed, during redisplay.
This patch accumulates Windows specific changes, winsys-independent
part is under way.
An RFC. There are now 2 ways to create an underlined face. One is to
specify font modifier 'underline', like "Courier
New:Regular:9:underline".
The other way is to create a non-underlined font, and set underline-p
property of the *face* to t. These faces won't be the same. Even worse,
the first face line height will be 1 greater than the second!
(Although, with 10pt size, they are same. Thanks Bill!).
Should the modifiers 'underline' and 'strikethru' go away from the
fonts?
Big K
2000-01-17 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
* faces.h (FACE_STRIKETHRU_P): Added.
* glyphs-msw.c (mswindows_widget_hfont): Implemented, to take care
of font variants.
* redisplay-msw.c (mswindows_apply_face_effects): Deleted.
(mswindows_set_dc_font): New function, aware of font variants,
separated from mswindows_update_dc.
* objects-msw.h (struct mswindows_font_instance_data): Added
definition.
* objects-msw.c (mswindows_finalize_font_instance): Delete all
cached fonts and the data structure.
(mswindows_initialize_font_instance): Added creation of font data
structure.
(mswindows_print_font_instance): Print at least something.
(mswindows_create_font_variant): Implemented.
(mswindows_get_hfont): Implemented.
------------------------------------------------------------------------
Name: kkm-2000-01-17-1
kkm-2000-01-17-1 Type: Plain Text (text/plain)
Encoding: quoted-printable
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be patient.
If you need an immediate response and it is not apparent in your message,
please say so. Thanks for your understanding.
5:24 a.m.
New subject: [PATCH] Use system underline and struck thru fonts
Some time ago, Ben Wing wrote...
The hope was the opposite -- eliminate the "font" property
and separate out
each individual property of it to a separate face property. The problem was,
there was disagreement over how to design this. Kyle wants to have a "font"
property containing a list of all the actual font properties. I think it's
arbitrary to distinguish between font and other properties, and that all
properties should be equal at the face level.
Why the opposite? Perhaps I misworded the question somehow. Second try. :)
Should underline and strike out properties go away from fonts and remain
only on the face level?
I agree with Ben. I wrote not the best code in my life just to separate
underline property of the font to be a property of the face, despite
that in Windows it is a property of the former. Not only the division
line between font and face properties is random, it is different in
Windows and in X. Faces should be -- eh -- homogenized?
Is it possible to kick fonts away form the lisp level at all? Fonts
are not abstract enough, faces are.
Big K
6:02 a.m.
New subject: [PATCH] Use system underline and struck thru fonts
Kirill 'Big K' Katsnelson writes:
Some time ago, Ben Wing wrote...
>The hope was the opposite -- eliminate the "font" property and
>separate out each individual property of it to a separate face
>property. The problem was, there was disagreement over how to
>design this. Kyle wants to have a "font" property containing a
>list of all the actual font properties. I think it's arbitrary
>to distinguish between font and other properties, and that all
>properties should be equal at the face level.
Why the opposite? Perhaps I misworded the question somehow. Second
try. :) Should underline and strike out properties go away from
fonts and remain only on the face level?
I agree with Ben. I wrote not the best code in my life just
to separate underline property of the font to be a property
of the face, despite that in Windows it is a property of the
former. Not only the division line between font and face
properties is random, it is different in Windows and in
X. Faces should be -- eh -- homogenized?
It isn't random, it is just not the same under X and under
Windows and under ttys. The differences are due to difference
in these environments. That's exactly why we should not add a
bunch of face properties for fonts. Let the differences be
encoded in the instantiators for the face's font specifier.
This way when the next operating system comes along, with yet
another font model, we won't have to change the low level API
once again to try to make everything look the same.
Is it possible to kick fonts away form the lisp level at all? Fonts
are not abstract enough, faces are.
I really don't want to do this. I don't want so much abstraction
that it is hard to specify a single font, simply and exactly. I
don't want to have to set fifteen face properties just to specify a
font. I don't want code that uses the existing API to be broken.
7:22 a.m.
New subject: [PATCH] Use system underline and struck thru fonts
Kyle Jones wrote:
Kirill 'Big K' Katsnelson writes:
> Some time ago, Ben Wing wrote...
> >The hope was the opposite -- eliminate the "font" property and
> >separate out each individual property of it to a separate face
> >property. The problem was, there was disagreement over how to
> >design this. Kyle wants to have a "font" property containing a
> >list of all the actual font properties. I think it's arbitrary
> >to distinguish between font and other properties, and that all
> >properties should be equal at the face level.
>
> Why the opposite? Perhaps I misworded the question somehow. Second
> try. :) Should underline and strike out properties go away from
> fonts and remain only on the face level?
>
> I agree with Ben. I wrote not the best code in my life just
> to separate underline property of the font to be a property
> of the face, despite that in Windows it is a property of the
> former. Not only the division line between font and face
> properties is random, it is different in Windows and in
> X. Faces should be -- eh -- homogenized?
It isn't random, it is just not the same under X and under
Windows and under ttys. The differences are due to difference
in these environments. That's exactly why we should not add a
bunch of face properties for fonts. Let the differences be
encoded in the instantiators for the face's font specifier.
This way when the next operating system comes along, with yet
another font model, we won't have to change the low level API
once again to try to make everything look the same.
> Is it possible to kick fonts away form the lisp level at all? Fonts
> are not abstract enough, faces are.
I really don't want to do this. I don't want so much abstraction
that it is hard to specify a single font, simply and exactly. I
don't want to have to set fifteen face properties just to specify a
font. I don't want code that uses the existing API to be broken.
Kyle, I don't have the hands to argue much. Let me just make a few
points:
1) Consensus is nice -- if we could agree, Kirill or someone else might
actually implement it ...
2) All of your objections are solvable in my model. You can probably
figure them out yourself if you take this model as given, e.g.
1. set-face-font becomes a compatibility function that sets the actual
properties; ibid for face-font
2. set-face-properties sets multiple properties easily (and is more
powerful without an arbitary font/no-font distinction)
3. I don't understand your arguments here, but they don't seem relevant:
It isn't random, it is just not the same under X and under
Windows and under ttys. The differences are due to difference
in these environments. That's exactly why we should not add a
bunch of face properties for fonts. Let the differences be
encoded in the instantiators for the face's font specifier.
This way when the next operating system comes along, with yet
another font model, we won't have to change the low level API
once again to try to make everything look the same.
ben
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be patient.
If you need an immediate response and it is not apparent in your message,
please say so. Thanks for your understanding.
6:03 a.m.
New subject: [PATCH] Use system underline and struck thru fonts
>>>> "kkm" == Kirill 'Big K' Katsnelson
<kkm(a)dtmx.com> writes:
kkm> Not only the division line between font and face properties
kkm> is random, it is different in Windows and in X. Faces should
kkm> be -- eh -- homogenized?
kkm> Is it possible to kick fonts away form the lisp level at all?
kkm> Fonts are not abstract enough, faces are.
No, it's not possible. There are four problems:
(1) The face properties may overspecify the font on any given system
(eg, color on a mono system, family on a TTY); in such a case the
face system will have to choose a compromise font. The user
should be able to override this arbitrary choice directly.
(2) The face properties may underspecify the font, in which case the
face system makes an arbitrary choice. Again, the user should be
able to override.
(3) Some font systems may provide properties the face system doesn't
know about. (This is really a special case of (2).) For example,
the X-TT family of X servers and font servers allows fonts with
arbitrary slants and weights to be created from a base font.
Should we deny users access to those features?
(4) Some characteristics that are important to users ("style") are
encoded as properties that may not map across character sets
("family": there may be -adobe-courier-*-iso-8859-5 for all I
know, but there is no -adobe-courier-*-jisx0208.1990-0) or may not
even be meaningful within a character set (most Unicode fonts have
a "family", but typically they are simply glommed together
versions of other fonts, and even from "good" vendors like
Microsoft you will occasionally find that Latin-1 and Latin-2
characters have quite different style).
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
7:01 a.m.
New subject: URGENT: CVS just trashed my source tree
This command in my 21.2 beta 20 tree updated the top directory as far
as I can tell but deleted all files without local modifications in
subdirectories:
cvs -z3 update -dP -rr21-2-21 2>&1 | tee cvs.update
issuing lots of messages like these:
cvs server: conflict: src/faces.c is modified but no longer in the repository
C src/faces.c
cvs server: conflict: src/faces.h is modified but no longer in the repository
C src/faces.h
and
cvs server: src/menubar.c is no longer in the repository
I hope this is just me or something with r21-2-21. The tag exists AFAICT.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:04 a.m.
New subject: URGENT: CVS just trashed my source tree
>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> This command in my 21.2 beta 20 tree updated the top directory as far
SJT> as I can tell but deleted all files without local modifications in
SJT> subdirectories:
SJT> cvs -z3 update -dP -rr21-2-21 2>&1 | tee cvs.update
SJT> issuing lots of messages like these:
SJT> cvs server: conflict: src/faces.c is modified but no longer in the repository
SJT> C src/faces.c
SJT> cvs server: conflict: src/faces.h is modified but no longer in the repository
SJT> C src/faces.h
SJT> and
SJT> cvs server: src/menubar.c is no longer in the repository
SJT> I hope this is just me or something with r21-2-21. The tag exists AFAICT.
I think it's just something with r21-2-21. That tag just didn't make
it to every file. Don't use that tag!
Note how r21-2-21 is missing below.
(martin＠lasker) /xemacs/ws/dev/src $ cvs log faces.c | grep r21-2-[0-9][0-9]
r21-2-26: 1.25.2.8
r21-2-25: 1.25.2.8
r21-2-24: 1.25.2.8
r21-2-23: 1.25.2.8
r21-2-22: 1.25.2.8
r21-2-20: 1.25.2.8
r21-2-19: 1.25.2.5
r21-2-18: 1.25.2.5
r21-2-17: 1.25.2.4
r21-2-16: 1.25.2.4
r21-2-15: 1.25.2.4
r21-2-14: 1.25.2.4
r21-2-13: 1.25.2.3
r21-2-12: 1.25.2.3
r21-2-11: 1.25.2.3
r21-2-10: 1.25.2.3
What are you doing with r21-2-21 anyways? Why not
cvs update -rrelease-21-2
(not that the current state of CVS could be considered stable).
There is an unreliability in the cvs tag command that I believe I have
worked around in the current release engineering script.
Martin
8:34 a.m.
New subject: URGENT: CVS just trashed my source tree
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> I think it's just something with r21-2-21. That tag just
mb> didn't make it to every file. Don't use that tag!
Thank you. Aha, r21-2-22 is coming along fine.
mb> What are you doing with r21-2-21 anyways?
The last release of UTF-2000 was for 21-2-19. I am not capable of
synching that code in one swell foop. I tried, it didn't work.
(Maybe if it were my day job....)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:23 a.m.
New subject: URGENT: CVS just trashed my source tree
>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> I think it's just something with
r21-2-21. That tag just
mb> didn't make it to every file. Don't use that tag!
SJT> Thank you. Aha, r21-2-22 is coming along fine.
mb> What are you doing with r21-2-21 anyways?
SJT> The last release of UTF-2000 was for 21-2-19. I am not capable of
SJT> synching that code in one swell foop. I tried, it didn't work.
SJT> (Maybe if it were my day job....)
UTF-2000 could be put on a CVS branch. This would involve learning a
fair bit about CVS, but then the boring part of the tough merging job
could be done by cvs, not you.
Martin
10:01 a.m.
New subject: UTF-2000 in in CVS tree? [was: CVS just trashed...]
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> UTF-2000 could be put on a CVS branch. This would involve
mb> learning a fair bit about CVS, but then the boring part of the
mb> tough merging job could be done by cvs, not you.
Hm? Last I heard, CVS didn't know how to fix # of arg mismatches, nor
how to deal with radical Olivier Galibert structure member
transplants. :-)
Nor do I "own" UTF-2000, that's Tomo's. I don't think he's
interested; but we could ask him again. There's also the ETL
licensing issue; Tomo claimed it's irrelevant, but I am not sure, at
least not without explicit statement from him.
If something comes of this (ie, a proposal for sensible architecture),
I'll discuss it with you again, but at the moment I don't want to
manage a branch that may simply die because the architecture becomes
obsolete. If somebody else is interested enough in UTF-2000 to manage
the branch themselves, I'd be happy to follow along.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
4:38 a.m.
New subject: UTF-2000 in in CVS tree? [was: CVS just trashed...]
Disregard the referenced messsage, it's no longer apropos.
Sorry about this out-of-sequence delivery, apparently it was in my
smail spool which proceeded to clean itself up for unknown reasons
this morning.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:45 a.m.
New subject: URGENT: CVS just trashed my source tree
At 04:01 PM 1/18/00 +0900, Stephen J. Turnbull wrote:
This command in my 21.2 beta 20 tree updated the top directory as far
as I can tell but deleted all files without local modifications in
subdirectories:
I had this last week. It was a real pain. I have a suspiscion that someone
was doing something to the repository at the time.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
9:45 a.m.
At 03:01 PM 1/17/00 -0800, Kirill 'Big K' Katsnelson wrote:
I am cleaning up the redisplay code to implement printing in Windows.
Excellent. This is way down my list - I assume you are going to use
redisplay to output to a printing DC?
I will apply this "momentarily"
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
9061
days inactive
9076
days old
13 comments
6 participants
participants (6)
-
Andy Piper -
Ben Wing -
Kirill 'Big K' Katsnelson -
Kyle Jones -
Martin Buchholz -
Stephen J. Turnbull