Not yet under the final license, but you can download from:
See: http://www.gnome.org/fonts for all the gory details.
Enjoy. - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
Thanks. I've tried them out but the quality in small sizes is not overly convincing. I've attached a small picture that shows Vera Sans in different sizes (VeraSansStrike.gif). Since the glyphs were generated using Squeak (w/ font plugin) I cannot judge the kerning (Squeak doesn't use the kerning pairs currently) but some of glyphs look problematic - for example, watch the "O" in line 1 and 3, the "b" in Line 2, the "ö" (o-umlaut) and question marks in line 4 the "N" in lines 5 and 6. The other fonts included look similar in quality; generally good fonts but somewhat poor at small sizes.
I've also tried with Yoshiki's TTF support and it looks better, yet at small sizes it is too washed out (see VeraSansTTF.gif). So it seems that while these fonts are nice they aren't really as great in small sizes.
BTW, someone wrote that these fonts are hinted - is this certain?! From the looks of it I see nothing that seems to go beyound regular drop-out support but maybe Windows (aka: the font plugin) is screwing me. I'd like to see if someone on a different platform can get "better results" than what I am seeing.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Jim.Gettys@hp.com Sent: Tuesday, February 25, 2003 5:43 PM To: squeak-dev@lists.squeakfoundation.org Subject: Beta test Bitstream Vera fonts available.
Not yet under the final license, but you can download from:
See: http://www.gnome.org/fonts for all the gory details.
Enjoy. - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
Sender: squeak-dev-bounces@lists.squeakfoundation.org From: "Andreas Raab" andreas.raab@gmx.de Date: Tue, 25 Feb 2003 23:15:48 +0100 To: "'The general-purpose Squeak developers list'" squeak-dev@lists.squeakfoundation.org Subject: RE: Beta test Bitstream Vera fonts available.
Thanks. I've tried them out but the quality in small sizes is not overly convincing. I've attached a small picture that shows Vera Sans in different sizes (VeraSansStrike.gif). Since the glyphs were generated using Squeak (w/ font plugin) I cannot judge the kerning (Squeak doesn't use the kerning pairs currently) but some of glyphs look problematic - for example, watch the "O" in line 1 and 3, the "b" in Line 2, the "ö" (o-umlaut) and question marks in line 4 the "N" in lines 5 and 6. The other fonts included look similar in quality; generally good fonts but somewhat poor at small sizes.
I've also tried with Yoshiki's TTF support and it looks better, yet at small sizes it is too washed out (see VeraSansTTF.gif). So it seems that while these fonts are nice they aren't really as great in small sizes.
BTW, someone wrote that these fonts are hinted - is this certain?! From the looks of it I see nothing that seems to go beyound regular drop-out support but maybe Windows (aka: the font plugin) is screwing me. I'd like to see if someone on a different platform can get "better results" than what I am seeing.
There are no delta hints in Vera: they will not generate good bitmaps at small sizes. They are intended for use primarily anti-aliased as we now do on Linux; antialiased, they do very well indeed at small sizes. Prima, from which Vera was derived, did have delta hints, but due to the procedure used to generate them, had bad results when imaged anti-aliased (alot of strokes went to zero width). (Bitstream has since changed how they generate their delta hints). But Vera is otherwise nicely hinted...
I use Vera very nicely on my iPAQ handheld at 6 pixels size :-)....
For some samples of where things are at using all open source technology, see: http://zap.crl.dec.com/Screenshot-4.png and http://zap.crl.dec.com/Screenshot3.png. This is best looked at on a flat panel with typical horizontal rgb subpixel order. Most things on those two shots are in one face of Vera or another....
One is of my desktop (yes, I do have MS Office installed on my Linux machine); the other is primarily a waterfall display app of one of the fonts.
There will be some additional work done on hinting over the next few weeks. You can see in the waterfall display a few characters need some additional TLC, as also you observed...
Here's the scoop:
Xft2 use Freetype for the basic rasterization; but that is just the start. Xft2 adjusts the hinting to keep things on pixel boundaries much more than Microsoft Cleartype does (which appears to at most adjust to subpixel bounadaries); we believe this is better, and I think the above shot of my desktop bears this out. The resulting glyphs are imaged at 3 times the horizontal or vertical resolution (depending on flatpanel subpixel order and orientation), and the results used to form a glyph which is alpha composited to the screen. This process Keith Packard calls subpixel decimation. So we end up a bit less faithful to the font outlines, but less fuzzy than Cleartype (which is sharper than not doing subpixel stuff is in the first place).
Xft2 will either use the X render extension for the alpha compositing, or will go down to pixels, alpha composite them to pixels extracted from the screen, and shove the pixels back to the screen if render isn't present. All the code is open source (MIT license). - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
On Wed, 2003-02-26 at 05:15, Jim.Gettys@hp.com wrote:
(looked at on a TFT screen)
This still doesn't one bit to convince me that antialiasing is a good idea for desktop fonts. For example, when looking at any word with a washed-out 'w', I constantly have to suppress the urge to take my glasses and wipe of some dirt.
I'll probably be a happy user of the good ol' bitmaps for quite some time to come, until displays go well above 100ppi :-)
On 26 Feb 2003 10:16:01 +0100, Cees de Groot cg@cdegroot.com wrote:
I'll probably be a happy user of the good ol' bitmaps for quite some time to come, until displays go well above 100ppi :-)
I have a 15" diagonal LCD screen on my laptop, which is pretty much exactly 12" across. The horizontal resolution is 1600, which makes the dot resolution around 133 ppi.
We're almost at that magical 150 ppi...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
Yes, W in Vera roman has some problems: I don't know yet if it is due to Vera, Freetype, or Xft2. On the list of characters/issues to deal with, as far as I'm concerned. As the w's are fine at some sizes, and not others, I think there is hope. Take a detailed look at the waterfall display, at w at other sizes, and other angled strokes; this looks to me most likely a hinting problem, or an out and out bug Vera is tickling.... - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
I plead for Multilingual Squeak (call it MLSQ) to become the responsiblity of the core Squeak maintainers. Here's why:
1. MLSQ is important for all of us in non US locales. We would wish all Squeak to be locale-agnostic: Any program should run in any locale.
2. For MLSQ to be transparent, it should therefore not require the programmer to understand any Unicode or other charset or encoding esoterica. MLSQ character processing should ideally isolate the programmer completely from the specificities of any multi-byte encoding.
3. Clearly, MLSQ needs to be designed carefully by specialists familiar with multi-byte issues. Reliability from the start is important. Therefore a cathedral-like initial design approach, with good documentation by the likes of Oshima-san and Abe-san makes sense, rather than letting mods accrete as it seems has happened with morphic.
4. However, a Multilingual separate distribution (like Nihongo Squeak), or a loadable add-on, DO NOT MAKE SENSE. Such a separate package will inevitably get out of sync with the current beta, get out of sync with newer add-ons, unnoticed bugs will lie dormant, and people will be too busy to rewrite their US-centric software to ensure compatibility with MLSQ, retroactively, when foreign users demand it.
5. If MLSQ is part of the core of every new distribution, any incompatibilities of MLSQ with standard tools will become immediately apparent. Furthermore, foreign users will immediately notice any issues with any new version in their own locales, at the alpha beta and gamma stages of each distribution and help nip them in the bud. As all software runs in any locale from the start, writers of add-ons will have bugs in multi-nationalization communicated to them by foreign beta-testers, allowing hackers to fumigate their add-on *before* it reaches maturity.
Which is why, again, I plead for internationalisation to be considered a core feature, to be intended from the start to be handed over to the core maintainers.
Edmund
Hi Jim,
There are no delta hints in Vera: they will not generate good bitmaps at small sizes. They are intended for use primarily anti-aliased as we now do on Linux; antialiased, they do very well indeed at small sizes.
Yup, that's what I thought.
For some samples of where things are at using all open source technology, see: http://zap.crl.dec.com/Screenshot-4.png and http://zap.crl.dec.com/Screenshot3.png. This is best looked at on a flat panel with typical horizontal rgb subpixel order. Most things on those two shots are in one face of Vera or another....
Looks very impressive. In particular the small fonts look not washed out at all and appear very readable at small sizes.
There will be some additional work done on hinting over the next few weeks. You can see in the waterfall display a few characters need some additional TLC, as also you observed...
*Grin* Compared to what I sent these look _perfect_ ;-)
Xft2 use Freetype for the basic rasterization; but that is just the start. Xft2 adjusts the hinting to keep things on pixel boundaries much more than Microsoft Cleartype does (which appears to at most adjust to subpixel bounadaries); we believe this is better, and I think the above shot of my desktop bears this out.
Absolutely agree. The quality is amazing. So Xft2 hacks the hinting?! Sounds somewhat scary ;-)
The resulting glyphs are imaged at 3 times the horizontal or vertical resolution (depending on flatpanel subpixel order and orientation), and the results used to form a glyph which is alpha composited to the screen. This process Keith Packard calls subpixel decimation. So we end up a bit less faithful to the font outlines, but less fuzzy than Cleartype (which is sharper than not doing subpixel stuff is in the first place).
How's the quality for non-LCD screens?! Plain old CRTs for example?
Cheers, - Andreas
Sender: squeak-dev-bounces@lists.squeakfoundation.org From: "Andreas Raab" andreas.raab@gmx.de Date: Wed, 26 Feb 2003 10:20:49 +0100 To: "'The general-purpose Squeak developers list'" squeak-dev@lists.squeakfoundation.org Subject: RE: Beta test Bitstream Vera fonts available.
Hi Jim,
There are no delta hints in Vera: they will not generate good bitmaps at small sizes. They are intended for use primarily anti-aliased as we now do on Linux; antialiased, they do very well indeed at small sizes.
Yup, that's what I thought.
For some samples of where things are at using all open source technology, see: http://zap.crl.dec.com/Screenshot-4.png and http://zap.crl.dec.com/Screenshot3.png. This is best looked at on a flat panel with typical horizontal rgb subpixel order. Most things on those two shots are in one face of Vera or another....
Looks very impressive. In particular the small fonts look not washed out at all and appear very readable at small sizes.
There will be some additional work done on hinting over the next few weeks. You can see in the waterfall display a few characters need some additional TLC, as also you observed...
*Grin* Compared to what I sent these look _perfect_ ;-)
Glad you think so. For the record, note that I have the TrueType hinter enabled on my machine in Freetype; dunno how you have it set.
The latest freetype's autohinter (used if TrueType possibly patented algorithms are not enabled) continues to improve btw.... What you get out of the box on Linux depends on the Linux distribution you use.
Xft2 use Freetype for the basic rasterization; but that is just the start. Xft2 adjusts the hinting to keep things on pixel boundaries much more than Microsoft Cleartype does (which appears to at most adjust to subpixel bounadaries); we believe this is better, and I think the above shot of my desktop bears this out.
Absolutely agree. The quality is amazing. So Xft2 hacks the hinting?! Sounds somewhat scary ;-)
Yes, Keith Packard can be a bit scary at times... :-) There is also one additional idea that could be tried; rather than keeping the character's strokes on pixel boundaries, keep a triad of subpixels together; that might allow better positioning of the glyphs on the line, but then the green subpixel would not necessarily be at the center (your eye is most sensitive to green). Dunno if Keith will ever try that one out. This all interacts in mystic ways with the human brain's signal processing system. Neurons are not the same as a DSP, and the only thing to do is to implement and see if you like it better. The human system has *really* sensitive edge detectors... And flat panels allow you to get *MUCH* sharper edges; exploiting that is a major feature...
Basically, you only get AA on pixels that would otherwise have ended up involved in jaggies...
The resulting glyphs are imaged at 3 times the horizontal or vertical resolution (depending on flatpanel subpixel order and orientation), and the results used to form a glyph which is alpha composited to the screen. This process Keith Packard calls subpixel decimation. So we end up a bit less faithful to the font outlines, but less fuzzy than Cleartype (which is sharper than not doing subpixel stuff is in the first place).
How's the quality for non-LCD screens?! Plain old CRTs for example?
Fine as far as I can tell. On plain old CRT's, you skip the subpixel stuff, of course, and CRT's add "natural" fuzz whether you like it or not. - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
At 8:47 AM -0800 2/26/03, Jim.Gettys@hp.com wrote:
Fine as far as I can tell. On plain old CRT's, you skip the subpixel stuff, of course, and CRT's add "natural" fuzz whether you like it or not.
But OTOH you *do* get better Nyquist filtering along the horizontal with something close to the right lowpass filter at the sampling limit. The lack of this in any dimension on flat panels is one of the big reasons why the pitch has to be so high on flat panel displays.
BTW, Color picking on CRTs for better antialiasing has been successfully used in the past by various folks and groups including the old Negroponte Architecture Machine Group at MIT. (So it can be done.)
Cheers,
Alan
At 8:47 AM -0800 2/26/03, Jim.Gettys@hp.com wrote:
Sender: squeak-dev-bounces@lists.squeakfoundation.org From: "Andreas Raab" andreas.raab@gmx.de Date: Wed, 26 Feb 2003 10:20:49 +0100 To: "'The general-purpose Squeak developers list'" squeak-dev@lists.squeakfoundation.org Subject: RE: Beta test Bitstream Vera fonts available.
Hi Jim,
There are no delta hints in Vera: they will not generate good bitmaps at small sizes. They are intended for use primarily anti-aliased as we now do on Linux; antialiased, they do very well indeed at small sizes.
Yup, that's what I thought.
For some samples of where things are at using all open source technology, see: http://zap.crl.dec.com/Screenshot-4.png and http://zap.crl.dec.com/Screenshot3.png. This is best looked at on a flat panel with typical horizontal rgb subpixel order. Most things on those two shots are in one face of Vera or another....
Looks very impressive. In particular the small fonts look not washed out at all and appear very readable at small sizes.
There will be some additional work done on hinting over the next few weeks. You can see in the waterfall display a few characters need some additional TLC, as also you observed...
*Grin* Compared to what I sent these look _perfect_ ;-)
Glad you think so. For the record, note that I have the TrueType hinter enabled on my machine in Freetype; dunno how you have it set.
The latest freetype's autohinter (used if TrueType possibly patented algorithms are not enabled) continues to improve btw.... What you get out of the box on Linux depends on the Linux distribution you use.
Xft2 use Freetype for the basic rasterization; but that is just the start. Xft2 adjusts the hinting to keep things on pixel boundaries much more than Microsoft Cleartype does (which appears to at most adjust to subpixel bounadaries); we believe this is better, and I think the above shot of my desktop bears this out.
Absolutely agree. The quality is amazing. So Xft2 hacks the hinting?! Sounds somewhat scary ;-)
Yes, Keith Packard can be a bit scary at times... :-) There is also one additional idea that could be tried; rather than keeping the character's strokes on pixel boundaries, keep a triad of subpixels together; that might allow better positioning of the glyphs on the line, but then the green subpixel would not necessarily be at the center (your eye is most sensitive to green). Dunno if Keith will ever try that one out. This all interacts in mystic ways with the human brain's signal processing system. Neurons are not the same as a DSP, and the only thing to do is to implement and see if you like it better. The human system has *really* sensitive edge detectors... And flat panels allow you to get *MUCH* sharper edges; exploiting that is a major feature...
Basically, you only get AA on pixels that would otherwise have ended up involved in jaggies...
The resulting glyphs are imaged at 3 times the horizontal or vertical resolution (depending on flatpanel subpixel order and orientation), and the results used to form a glyph which is alpha composited to the screen. This process Keith Packard calls subpixel decimation. So we end up a bit less faithful to the font outlines, but less fuzzy than Cleartype (which is sharper than not doing subpixel stuff is in the first place).
How's the quality for non-LCD screens?! Plain old CRTs for example?
Fine as far as I can tell. On plain old CRT's, you skip the subpixel stuff, of course, and CRT's add "natural" fuzz whether you like it or not. - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
--
This is neat, Jim!
Cheers,
Alan
------
At 8:15 PM -0800 2/25/03, Jim.Gettys@hp.com wrote:
Sender: squeak-dev-bounces@lists.squeakfoundation.org From: "Andreas Raab" andreas.raab@gmx.de Date: Tue, 25 Feb 2003 23:15:48 +0100 To: "'The general-purpose Squeak developers list'" squeak-dev@lists.squeakfoundation.org Subject: RE: Beta test Bitstream Vera fonts available.
Thanks. I've tried them out but the quality in small sizes is not overly convincing. I've attached a small picture that shows Vera Sans in different sizes (VeraSansStrike.gif). Since the glyphs were generated using Squeak (w/ font plugin) I cannot judge the kerning (Squeak doesn't use the kerning pairs currently) but some of glyphs look problematic - for example, watch the "O" in line 1 and 3, the "b" in Line 2, the "ö" (o-umlaut) and question marks in line 4 the "N" in lines 5 and 6. The other fonts included look similar in quality; generally good fonts but somewhat poor at small sizes.
I've also tried with Yoshiki's TTF support and it looks better, yet at small sizes it is too washed out (see VeraSansTTF.gif). So it seems that while these fonts are nice they aren't really as great in small sizes.
BTW, someone wrote that these fonts are hinted - is this certain?! From the looks of it I see nothing that seems to go beyound regular drop-out support but maybe Windows (aka: the font plugin) is screwing me. I'd like to see if someone on a different platform can get "better results" than what I am seeing.
There are no delta hints in Vera: they will not generate good bitmaps at small sizes. They are intended for use primarily anti-aliased as we now do on Linux; antialiased, they do very well indeed at small sizes. Prima, from which Vera was derived, did have delta hints, but due to the procedure used to generate them, had bad results when imaged anti-aliased (alot of strokes went to zero width). (Bitstream has since changed how they generate their delta hints). But Vera is otherwise nicely hinted...
I use Vera very nicely on my iPAQ handheld at 6 pixels size :-)....
For some samples of where things are at using all open source technology, see: http://zap.crl.dec.com/Screenshot-4.png and http://zap.crl.dec.com/Screenshot3.png. This is best looked at on a flat panel with typical horizontal rgb subpixel order. Most things on those two shots are in one face of Vera or another....
One is of my desktop (yes, I do have MS Office installed on my Linux machine); the other is primarily a waterfall display app of one of the fonts.
There will be some additional work done on hinting over the next few weeks. You can see in the waterfall display a few characters need some additional TLC, as also you observed...
Here's the scoop:
Xft2 use Freetype for the basic rasterization; but that is just the start. Xft2 adjusts the hinting to keep things on pixel boundaries much more than Microsoft Cleartype does (which appears to at most adjust to subpixel bounadaries); we believe this is better, and I think the above shot of my desktop bears this out. The resulting glyphs are imaged at 3 times the horizontal or vertical resolution (depending on flatpanel subpixel order and orientation), and the results used to form a glyph which is alpha composited to the screen. This process Keith Packard calls subpixel decimation. So we end up a bit less faithful to the font outlines, but less fuzzy than Cleartype (which is sharper than not doing subpixel stuff is in the first place).
Xft2 will either use the X render extension for the alpha compositing, or will go down to pixels, alpha composite them to pixels extracted from the screen, and shove the pixels back to the screen if render isn't present. All the code is open source (MIT license). - Jim
-- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys@hp.com
--
Hi Guys,
While trying to play with the Vera fonts I tried to install the Win32Fonts from Squeakmap. I had done this before and it always worked but not today. Debugging the problem I found the cause of this be ZipArchive>>extractMember:toFileNamed: which will _always_ extract to a relative path even if an absolute one is given. E.g., evaluating something like:
aZipArchive extractMember: 'foo.bar' toFileNamed: 'D:\My Squeak\foo.bar'
will actually result in putting the file foo.bar into '<image directory>\My Squeak\foo.bar'. This can't be right - if we give the archive an absolute path to extract something to, why would it forcefully interpret this as a relative one and even skip the drive?!
This change must have happened recently as I have successfully installed this very package at various times in the past. I don't know if any other packages are affected by this but I think it's worthwhile to check.
Cheers, - Andreas
Hi Guys,
I seem to have it with ZipArchive today. I was hunting a bug in the project publishing code in the Squeakland plugin and just happened to use a 3.4 image (I still had it open since I was playing with the Vera fonts - see the other message). It broke immediately which (at first) I happily thought was the problem I am looking for (the symptoms were "right").
Unfortunately it wasn't. Turns out that ZipArchiveMember>>fileName was changed to return a platform-specific path which breaks the entire resource management machinery (both publishing and loading) relying on the fact that zip archives contain "canonical" unix-style path names (if any). In short, that makes eToys unusable in 3.4 since all "reasonably complex" sketches drawn with 3.4 will come out as scaled stubs only (e.g., they will look horribly washed out - see attached pictures).
Any ideas?
Cheers, - Andreas
On Tuesday 25 February 2003 02:55 pm, Andreas Raab wrote:
Hi Guys,
I seem to have it with ZipArchive today. I was hunting a bug in the project publishing code in the Squeakland plugin and just happened to use a 3.4 image (I still had it open since I was playing with the Vera fonts - see the other message). It broke immediately which (at first) I happily thought was the problem I am looking for (the symptoms were "right").
Unfortunately it wasn't. Turns out that ZipArchiveMember>>fileName was changed to return a platform-specific path which breaks the entire resource management machinery (both publishing and loading) relying on the fact that zip archives contain "canonical" unix-style path names (if any). In short, that makes eToys unusable in 3.4 since all "reasonably complex" sketches drawn with 3.4 will come out as scaled stubs only (e.g., they will look horribly washed out - see attached pictures).
Do you have CS 5161 loaded? That CS reverted that particular breakage.
fileName should return whatever's in the Zip.
From the preamble to 5161:
My recent changes to fileName in ArchiveMember broke project loading in non-Unix systems.
This reverts fileName so that it returns the raw Zip name, and adds localFileName for use when you need a name that's compatible with the local file system.
Hi Ned,
Do you have CS 5161 loaded? That CS reverted that particular breakage.
Yes, I do. But I see that SARInstallerFor34-nk (loaded probably when I opened up the SqueakMap loader) makes that change, too. So that's why I saw it after loading the stuff from SM first. Looks like the package needs a little update.
Thanks for pointing this out!
Cheers, - Andreas
On Tuesday 25 February 2003 04:14 pm, Andreas Raab wrote:
Hi Ned,
Do you have CS 5161 loaded? That CS reverted that particular breakage.
Yes, I do. But I see that SARInstallerFor34-nk (loaded probably when I opened up the SqueakMap loader) makes that change, too. So that's why I saw it after loading the stuff from SM first. Looks like the package needs a little update.
Thanks for pointing this out!
Do you mean that SARInstaller breaks this? I'll have to look at it.
Do you mean that SARInstaller breaks this?
Yup, looks like it. It seems that it includes various changes to Archive etc. including the one that caused the problem. I didn't actually realize how much stuff is being changed when the SM browser is loaded. Besides the problem reported I could see that for example, DVS will not work correctly with various classes implementing #noteCompilationOf:meta: which it apparently uses for recording modifications. Some of those (including Morph class) reimplement this message without calling their super versions and since DVS patches its version "inbetween" it won't work on those classes.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Wednesday, February 26, 2003 1:28 AM To: The general-purpose Squeak developers list Subject: Re: [BUG][3.4] Etoys broken due to ZipArchiveMember>>fileName
On Tuesday 25 February 2003 04:14 pm, Andreas Raab wrote:
Hi Ned,
Do you have CS 5161 loaded? That CS reverted that particular breakage.
Yes, I do. But I see that SARInstallerFor34-nk (loaded probably when I opened up the SqueakMap loader) makes that change, too. So that's why I saw it after loading the stuff from SM first. Looks like the package needs a little update.
Thanks for pointing this out!
Do you mean that SARInstaller breaks this? I'll have to look at it.
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
On Tuesday 25 February 2003 04:42 pm, Andreas Raab wrote:
Besides the problem reported I could see that for example, DVS will not work correctly with various classes implementing #noteCompilationOf:meta: which it apparently uses for recording modifications. Some of those (including Morph class) reimplement this message without calling their super versions and since DVS patches its version "inbetween" it won't work on those classes.
Do you think there would be any problem with putting super calls in Morph and StandardScriptingSystem classes?
I'm sure that Avi could add this to DVS.
I'm still trying to figure out the best way to handle the archive fixes for the SARInstaller: whether to
1) add the three later change sets (that SARInstaller broke by being older) to the SARInstaller package and get the zip fixes, even if you load it into an image that is older than 5161
or
2) put the three later change sets into a separate .cs on SqueakMap to be used to repair existing images (and older ones)
or
3) both of the above
On Tuesday 25 February 2003 02:55 pm, Andreas Raab wrote:
In short, that makes eToys unusable in 3.4 since all "reasonably complex" sketches drawn with 3.4 will come out as scaled stubs only (e.g., they will look horribly washed out - see attached pictures).
Have you tried this with 3.4gamma (i.e 5168 or so)?
I just tried this in Windows, and was able to save and properly restore a project with a JPEG in it.
On Tuesday 25 February 2003 02:25 pm, Andreas Raab wrote:
Debugging the problem I found the cause of this be ZipArchive>>extractMember:toFileNamed: which will _always_ extract to a relative path even if an absolute one is given. E.g., evaluating something like:
aZipArchive extractMember: 'foo.bar' toFileNamed: 'D:\MySqueak\foo.bar'
will actually result in putting the file foo.bar into '<image directory>\My Squeak\foo.bar'. This can't be right - if we give the archive an absolute path to extract something to, why would it forcefully interpret this as a relative one and even skip the drive?!
This change must have happened recently as I have successfully installed this very package at various times in the past. I don't know if any other packages are affected by this but I think it's worthwhile to check.
I'll take a look at this.
"Andreas Raab" andreas.raab@gmx.de wrote:
Hi Guys,
While trying to play with the Vera fonts I tried to install the Win32Fonts from Squeakmap. I had done this before and it always worked but not today.
[SNIP of description etc. Ned later found the problem btw]
This reminds me of an interesting "piece of the Squeak puzzle" I have been thinking about. Perhaps someone is interested in implementing it. The idea is to create a "build server" that simply just wastes CPU by installing packages from SM and verifying that the install at least works without throwing an Exception.
Of course, as we all know - this is hard to implement today since the dependencies aren't here yet, but hopefully they will be soon. So this little "build server" could evolve into an elaborate integration tester. It could not only install single packages but of course combinations of packages (think load scripts for example) and it could also execute test suites for the packages to see that they are "ok".
So... anyone interested? I am fully aware that this system is pretty heavily dependent on SM1.1 but someone could start on it.
Anyway, this kind of system could (perhaps) have caught the above problem.
regards, Göran
On Tue, 2003-02-25 at 23:25, Andreas Raab wrote:
This can't be right - if we give the archive an absolute path to extract something to, why would it forcefully interpret this as a relative one and even skip the drive?!
I think it is a Good Think and I hope it was a modification done on purpose. If you disagree, I'll be happy to put a SAR up on SM with files like 'C:\WINDOWS..whatever kills your system...'
The ZIP is broken for having absolute paths, IMNSHO.
Cees,
On Tue, 2003-02-25 at 23:25, Andreas Raab wrote:
This can't be right - if we give the archive an absolute path to extract something to, why would it forcefully
interpret this as a
relative one and even skip the drive?!
I think it is a Good Think and I hope it was a modification done on purpose. If you disagree, I'll be happy to put a SAR up on SM with files like 'C:\WINDOWS..whatever kills your system...'
This argument seems bogus to me. For one thing, it can be equally problematic to put something relative to the image directory - who says there's nothing in there?! For another one, just because you _can_ do bad things doesn't mean there is no good use for absolute paths. In the concrete case, for example, the Win32Fonts installer attempts to put the font plugin into the VM directory - a perfectly legal behavior in my opinion. Thirdly, "just" having ZipArchive behave this way, doesn't solve any problem whatsoever unless you prevent people from changing/deleting files generally. If you (or your OS) do so, then there's no reason for the ZipArchive to behave that way.
The ZIP is broken for having absolute paths, IMNSHO.
The ZIP itself doesn't have any absolute paths. The installer script asks the archive to extract the font plugin to the place where the VM lives (due to Smalltalk>>vmPath that's an absolute location).
Please keep in mind that my major argument here is that if we request to extract a file to some clearly specified absolute location then ZipArchive should adhere to this request. If it doesn't it will only confuse people - yes, they can work around this (simply open the file yourself and copy the stuff into it) but that seems pretty awkward to me.
Cheers, - Andreas
On Wed, 2003-02-26 at 12:31, Andreas Raab wrote:
This argument seems bogus to me.
Well, it's an argument that has been rehashed over and over again in a slightly different context, and was at last resolved in favour of making abolute pathnames relative by default (GNU tar). I refer you to the GNU tar mailing list archives (probably somewhere around 1990) for the gory details ;-)
On Wed, 2003-02-26 at 12:31, Andreas Raab wrote:
This can't be right - if we give the archive an absolute path to extract something to, why would it forcefully
My apologies - I misread this sentence. If you tell it to extract in a certain directory, it should extract below it; I was mixing it up with absolute pathnames inside the ZIP.
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Cees de Groot -
Edmund Ronald -
goran.hultgren＠bluefish.se -
Jim.Gettys＠hp.com -
Jon Hylands -
Ned Konz