That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused, in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other.
So, it's a mere matter of applying the nicest package that's on SM as soon as we're ready to start rolling updates for 3.5.
Cool. I love Squeak. Thanks Andreas.
Daniel
Andreas Raab andreas.raab@gmx.de wrote:
Hi guys,
Just to throw in an extra thought into this discussion: If you are concerned that switching the default encoding for fonts would prevent you from using any of the existing fonts you are wrong. The fonts in Squeak contain a character to glyph mapping so that any existing font (in any encoding) can be used even if the default character set is changed. In other words, all that's needed for all of the existing fonts is a WhateverWeDecide -> Mac Roman mapping and that's it. I have used this mechanism (for example) for the native font support on Windows.
Cheers,
- Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ian Piumarta Sent: Monday, February 24, 2003 7:52 PM To: Daniel Vainsencher Cc: squeak-dev@lists.squeakfoundation.org Subject: Re: Adding Accufonts to the update stream (was Re: LicencesQuestion : Squeak-L Art 6.)
Daniel,
On Mon, 24 Feb 2003, Daniel Vainsencher wrote:
Ian, do you see a problem
I see only opportunities. ;)
with loading AccuFonts to solve the license issues now
Somebody who has replaced (and lived with) the standard fonts entirely with them would be a better judge. But if the glyphs are in the right places then the change should be completely transparent as far as the image and VMs are concerned.
and then doing as you guys propose as soon as we have everything lined up? the VMs, image enhancements like
keyboard shortcut
you proposed, and more (reasonable) amount of discussion to
make sure we
didn't miss anything?
The VM changes are minimal. They'd take 15 minutes, tops.
The only thing we (I) missed was that most of the _fixed_-width X fonts (e.g, xc/fonts/bdf/misc/6x13-ISO8859-1.bdf) come with this copyright:
Public domain font. Share and enjoy.
whereas the proportional fonts (times, helvetica) and courrier are not copyright-free, and come with this one (again snipped directly from a bdf file; e.g., xc/fonts/bdf/75dpi/helvR10-ISO8859-1.bdf):
Copyright 1984-1989, 1994 Adobe Systems Incorporated. Copyright 1988, 1994 Digital Equipment Corporation.
Adobe is a trademark of Adobe Systems Incorporated which may be registered in certain jurisdictions. Permission to use these trademarks is hereby granted only in association with the images described in this file.
Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notices appear in all copies and that both those copyright notices and this permission notice appear in supporting documentation, and that the names of Adobe Systems and Digital Equipment Corporation not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Adobe Systems and Digital Equipment Corporation make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
But that's just standard X boilerplate, entirely Squeak-friendly, and as someone pointed out the other day requires only being tacked on the end of the license file.
Ian
Daniel,
That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused, in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other.
Well, actually, that's not _quite_ true. Changing the default character encoding *does* require VM support. And, doing so *will* introduce a certain amount of incompatibility. The point I was making is that "our daily use of fonts" is not necessarily affected (e.g., changing the default encoding does not necessarily affect whether you can use any of the fonts currently in Squeak).
The reason why it introduces a certain amount of incompatibility is that the character sets are not to 100% compatible. Some glyphs appear in some of them, others don't. If there is no equivalent for a certain glyph in some font you will have some incompatibility. Yet, for the vast amount of characters in the fonts this will not be an issue (the only ones I can think about where this might cause a problem are 'decorative glyphs' such as bullets) since the glyphs are "reasonably compatible" across the major encoding families for latin fonts.
I also think that changing the default character encoding would be very worthwhile. As it is, we use a default encoding which is no longer actively supported (e.g., even Macs essentially emulate it today) and that means that as we are moving towards different fonts we will have more and more "holes" in the character sets - glyphs that are not in Mac Roman but not in others and glyphs that are in others and not in Mac Roman will have to be left out.
Cheers, - Andreas
-----Original Message----- From: Daniel Vainsencher [mailto:danielv@netvision.net.il] Sent: Monday, February 24, 2003 10:50 PM To: The general-purpose Squeak developers list Cc: ian.piumarta@inria.fr; Andreas Raab Subject: RE: Adding Accufonts to the update stream (was Re: LicencesQuestion : Squeak-L Art 6.)
That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused, in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other.
So, it's a mere matter of applying the nicest package that's on SM as soon as we're ready to start rolling updates for 3.5.
Cool. I love Squeak. Thanks Andreas.
Daniel
Andreas Raab andreas.raab@gmx.de wrote:
Hi guys,
Just to throw in an extra thought into this discussion: If
you are concerned
that switching the default encoding for fonts would prevent
you from using
any of the existing fonts you are wrong. The fonts in
Squeak contain a
character to glyph mapping so that any existing font (in
any encoding) can
be used even if the default character set is changed. In
other words, all
that's needed for all of the existing fonts is a
WhateverWeDecide -> Mac
Roman mapping and that's it. I have used this mechanism
(for example) for
the native font support on Windows.
Cheers,
- Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ian Piumarta Sent: Monday, February 24, 2003 7:52 PM To: Daniel Vainsencher Cc: squeak-dev@lists.squeakfoundation.org Subject: Re: Adding Accufonts to the update stream (was Re: LicencesQuestion : Squeak-L Art 6.)
Daniel,
On Mon, 24 Feb 2003, Daniel Vainsencher wrote:
Ian, do you see a problem
I see only opportunities. ;)
with loading AccuFonts to solve the license issues now
Somebody who has replaced (and lived with) the standard
fonts entirely
with them would be a better judge. But if the glyphs are
in the right
places then the change should be completely transparent
as far as the
image and VMs are concerned.
and then doing as you guys propose as soon as we have everything lined up? the VMs, image enhancements like
keyboard shortcut
you proposed, and more (reasonable) amount of discussion to
make sure we
didn't miss anything?
The VM changes are minimal. They'd take 15 minutes, tops.
The only thing we (I) missed was that most of the _fixed_-width X fonts (e.g, xc/fonts/bdf/misc/6x13-ISO8859-1.bdf) come with
this copyright:
Public domain font. Share and enjoy.
whereas the proportional fonts (times, helvetica) and
courrier are not
copyright-free, and come with this one (again snipped directly from a bdf file; e.g., xc/fonts/bdf/75dpi/helvR10-ISO8859-1.bdf):
Copyright 1984-1989, 1994 Adobe Systems Incorporated. Copyright 1988, 1994 Digital Equipment Corporation.
Adobe is a trademark of Adobe Systems Incorporated which may be registered in certain jurisdictions. Permission to use these trademarks is hereby granted only in association with the images described in this file.
Permission to use, copy, modify, distribute and sell
this software
and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notices appear in all copies and that both those copyright notices and this permission notice appear in supporting documentation, and that the names of Adobe Systems and Digital Equipment Corporation not be used in advertising or publicity pertaining to distribution of
the software
without specific, written prior permission. Adobe Systems and Digital Equipment Corporation make no representations about the suitability of this software for any purpose. It is
provided "as
is" without express or implied warranty.
But that's just standard X boilerplate, entirely
Squeak-friendly, and
as someone pointed out the other day requires only being
tacked on the
end of the license file.
Ian
On Monday, February 24, 2003, at 03:51 PM, Andreas Raab wrote:
Daniel,
That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused, in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other.
Well, actually, that's not _quite_ true. Changing the default character encoding *does* require VM support. And, doing so *will* introduce a certain amount of incompatibility. The point I was making is that "our daily use of fonts" is not necessarily affected (e.g., changing the default encoding does not necessarily affect whether you can use any of the fonts currently in Squeak).
I was wondering about that, right now characters come whizzing up from the VM event handler get manipulated into a string, then back down to the file support where we assume they are macroman and get converted back to what makes the file system happy. Changing where this mapping happens in Smalltalk (if it does) doesn't fix issue with arbitrary strings in the image that are perhaps valid macroman file names, this is one place there is an issue, not sure about others, clipboard support I'd guess.
As an example I'll point out somewhere I got bit many years ago, when VW moved to unicode. In this app we stored logonid for oracle in what we thought was strings. However upon a migration to NT it turned out that VW now extruded the characters as unicode because the file system support unicode by default, and when we present the characters to the primitive interface as unicode, where before they were ascii, then interesting bad things happened. It took a while to figure out because all the tools cheerfully did the unicode translation required. Only in the low level debugger could we see the data wasn't right.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Tue, 25 Feb 2003, Daniel Vainsencher wrote:
That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused,
See Andreas's reply on the issues (and my comments about "lossy" conversions in an earlier post).
in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other.
Just registered on SqueakMap: X11Fonts. It's a SAR that will install ISO-8859-15(Latin9)-encoded TimesRoman, Helvetica, Courier and Fixed in various point sizes as system fonts. Install tested in a vanilla 3.4g1 image. Sorry if it breaks for anyone else: it's the first SAR I ever tried to build.
Note that it does _not_ modify any existing fonts. (The Apple fonts remain installed and available.)
Note also that left arrow is underscore in these fonts, and we need to think about how to deal with this. I'm for moving it to an unused slot in the encoding and then having a VM preference (or parameter or whatever) to have the `_' key (or whichever ;) reported as the new left arrow charcode. E.g., the range 127 through 159 (inclusive) is unused in 8859-15. 127 would seem to be a good choice since it doesn't clash with WinLatin-x (should anyone decide to add the additional glyphs); otherwise 129, 141, 143, 144 and 157 are also unassigned in CP1252 (aka WinLatin1).
This would of course leave somebody with the task of replacing all left arrow characters in the 3.5 .changes file with the new charcode and then convincing themselves that nothing broke in the process.
If anyone wants to play with these in earnest (e.g., with the symbols, accented chars and ligatures working they way they should) then I would be prepared to make the corresponding VM modifications in my 3.5-devel sources and build new binaries. (But maybe not for a day or two.)
Ian
Yeah! Nice fonts! Thanks a lot. Hey, can you make up TTFs from those Type 1 fonts you were talking about?! I'd love to use them with Yoshiki's stuff too ;-)
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ian Piumarta Sent: Wednesday, February 26, 2003 1:32 AM To: squeak-dev@lists.squeakfoundation.org Subject: [GOODIE] X11Fonts (was RE: Adding Accufonts to the update stream)
On Tue, 25 Feb 2003, Daniel Vainsencher wrote:
That, IIUC, means both that no VM changes is needed, and that no incompatibility is caused,
See Andreas's reply on the issues (and my comments about "lossy" conversions in an earlier post).
in which case, it's merely a matter of creating another font package to put SM, and either should be installable after the other.
Just registered on SqueakMap: X11Fonts. It's a SAR that will install ISO-8859-15(Latin9)-encoded TimesRoman, Helvetica, Courier and Fixed in various point sizes as system fonts. Install tested in a vanilla 3.4g1 image. Sorry if it breaks for anyone else: it's the first SAR I ever tried to build.
Note that it does _not_ modify any existing fonts. (The Apple fonts remain installed and available.)
Note also that left arrow is underscore in these fonts, and we need to think about how to deal with this. I'm for moving it to an unused slot in the encoding and then having a VM preference (or parameter or whatever) to have the `_' key (or whichever ;) reported as the new left arrow charcode. E.g., the range 127 through 159 (inclusive) is unused in 8859-15. 127 would seem to be a good choice since it doesn't clash with WinLatin-x (should anyone decide to add the additional glyphs); otherwise 129, 141, 143, 144 and 157 are also unassigned in CP1252 (aka WinLatin1).
This would of course leave somebody with the task of replacing all left arrow characters in the 3.5 .changes file with the new charcode and then convincing themselves that nothing broke in the process.
If anyone wants to play with these in earnest (e.g., with the symbols, accented chars and ligatures working they way they should) then I would be prepared to make the corresponding VM modifications in my 3.5-devel sources and build new binaries. (But maybe not for a day or two.)
Ian
Hi Andreas,
Hey, can you make up TTFs from those Type 1 fonts you were talking about?!
See if you can make any sense of this:
http://www-sor.inria.fr/~piumarta/cmr12.ttf
If it works and looks nice then I'll try to convert the entire series.
Cheers, Ian
See if you can make any sense of this:
http://www-sor.inria.fr/~piumarta/cmr12.ttf
If it works and looks nice then I'll try to convert the entire series.
It does! Thanks a lot.
Cheers, - Andreas
Cool, Ian!
On the topic of X11 fonts I have one issue: if you use, say, Helvetica as the flaps font, the texts are cropped. Is there an easy fix to that?
On Wed, 2003-02-26 at 01:32, Ian Piumarta wrote:
Note that it does _not_ modify any existing fonts. (The Apple fonts remain installed and available.)
I've been through ugly code in order to get the Apple fonts GC'ed away, like:
"necessary for NewYork and Comic" StrikeFont allInstances do: [:font | (font name beginsWith: 'Comic') ifTrue: [ (Smalltalk pointersTo: font) do: [:each | (each respondsTo: #font:) ifTrue: [ each font: (StrikeFont familyName: 'Helvetica' size: 12)]]]]
TextStyle allInstances do: [:style | (style name beginsWith: 'a TextStyle NewYork') ifTrue: [ (Smalltalk pointersTo: style) do: [:each | (each respondsTo: #setTextStyle:) ifTrue: [ each setTextStyle: (TextStyle default)]]]]
The end result wasn't perfect, and I might have forgotten to keep a log on some tweaks, but the end result was that the Apple fonts could be GC'ed. And probably I got it all wrong, too (I'm a complete nitwit in the area of Smalltalk GUI's), but I thought I'd post my code anyway - hopefuly someone comes up with something cleaner ;-). Anyway, the code above was purely meant to see whether I could remove the Apple fonts, treat it as such ;-)
Ian Piumarta ian.piumarta@inria.fr wrote on Wednesday, February 26, 2003 1:32 AM
Just registered on SqueakMap: X11Fonts. It's a SAR that will install ISO-8859-15(Latin9)-encoded TimesRoman, Helvetica, Courier and Fixed in various point sizes as system fonts. Install tested in a vanilla 3.4g1 image. Sorry if it breaks for anyone else: it's the first SAR I ever tried to build.
Thank you for doing that, Jan. I just loaded your fonts into a fresh 3.4 image. They look fine, but ... :-(
I have the impression that with the exception of the fixed width fonts they all have a small bug: Some of the glyphs at the highest code points are not present. The attached screenshot shows this for the largest size of Helvetica. (a very beautiful font that will certainly find users) Inspection of this font reveals that the form 'glyphs' has a width of 2387 pixels, but array 'xTable' contains coordinates up to 2566.
You certainly loaded the fonts from BDF-files and created sf2-files with method StrikeFont>>writeAsStrike2On: Reading of BDF-files changes recently and perhaps the form 'glyphs' is created to small during reading. What do you think about it?
I will try to look at this stuff again during the weekend.
For now my cordial greetings and thank you again for doing that work
Boris
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Boris Gaertner -
Cees de Groot -
Daniel Vainsencher -
Ian Piumarta -
John M McIntosh