Squeak-dev January 2004

squeak-dev@lists.squeakfoundation.org

156 participants
396 discussions

Start a nNew thread

RE: rich text in Squeak
by Darius 02 Jan '04

02 Jan '04

Could Open Office provide the ideal, standard, multi-lingual, multi-platform rich text format for Squeak?

4 3

[BUG] BFAV 2.1 downgrades prerequisite packages
by Ned Konz 02 Jan '04

02 Jan '04

I had Monticello v.64 or so installed; the BFAV install downgraded it to the version on SqueakMap, even though I had a newer version.

1 0

Re: SmallWiki and Images
by michael.cole＠nimiq.net 01 Jan '04

01 Jan '04

Lukas and Avi, Thanks for the quick responses, but something is not working for me. When I follow Lukas's point that when a new link *my fine picture* is created, one can then upload the data to define the resource. When I do this (using a .jpg, .png image) and keep 'emedded' enabled, the image link is created but it is not inlined to the page. FWIW, going to the page holding the resources shows the mime type as 'unknown'. Have I missed something blindingly obvious? Happy new year, Michael Lukas Renggli <renggli(a)student.unibe.ch> wrote: > >>> Is there a way to have embedded images in a SmallWiki page? All I > >>> seem to be able to do is to set up a link to the image. > >> > >> yes this is the way to go: simply create a link from your wiki-page > >> to the resource and the image should be inlined automatically. As an > >> example you might want to check out this page: > >> > >> http://kilana.unibe.ch:9090/ese2003gruppen-smallwikis/ > >> sureshockwriters/ > > > > Hm. That shows a link to *ssw-image* as if it were a wiki page - is > > there some way to upload and name an image, then? > > Yes, but as it points to a resource it is rendered differently according > to its mime-type: that means if it is an image an <img>, if it is a > movie an <object>, etc. is emitted. > > When creating a new link *The New Image* to a non existant structure in > SmallWiki at first the link doesn't point to anything. However on the > html-page a list with all the possible structures (depending of the > security configuration for the current user not all possibliites might > be shown) will be rendered and the user can choose what he wants to > point this link to. In the given example one would click on 'Resource' > and an upload-dialog will be presented where the user specifies the file > to upload. When hitting ok, a new resource named 'The New Image' is > created and the user is brought back to the original page displaying now > the image now inlined. >

2 1

[BUG][FIX][VMMaker]InterpreterPlugin-halt
by Yoshiki Ohshima 01 Jan '04

01 Jan '04

Hello, The receiver of the halt message in InterpreterPlugin>>halt shouldn't be self because it'll end up with an infinite loop. Probably, nil would be good instead. Attached is the fix. -- Yoshiki

1 0

SmallWiki and Images
by michael.cole＠nimiq.net 01 Jan '04

01 Jan '04

Hi, Is there a way to have embedded images in a SmallWiki page? All I seem to be able to do is to set up a link to the image. Thanks, Michael Cole

3 3

EPS export strangeness
by Ned Konz 01 Jan '04

01 Jan '04

I'm trying to get the Postscript export working for my Connectors documentation. I have fixed a couple of problems with the Bezier drawing (like using eofill rather than fill), and am now attacking the polygon drawing and filling. However, I'm a bit puzzled about a few things (note that I really am NOT a Postscript programmer): - The bounding box in the EPS output is too small by the 10x10 offset that is added, so the right edge of the printed Morph is clipped, and the morph is not centered in the resultant bbox. - For some reason, PostscriptCanvas>>frameAndFillRectangle:fillColor:borderWidth:topLeftColor:bottomRightColor: draws an "inset border" on all filled, bordered rectangles -- even if the border style isn't inset! Is this *really* what we want? Wouldn't it make more sense to try to reproduce the *actual* style of the border? - When exporting a Morph as Postscript, we use an extension of '.eps' even when not writing a valid EPS file (however, the file is much closer to a valid EPS file if you set the postscriptStoredAsEPS preference). Perhaps we should use a '.ps' extension when not writing an EPS. - EPS files aren't supposed to do 'showpage', but we put one at the end of the file. Should we? And we go to some lengths to redefine showpage so it's bracketed with a gsave/ grestore. Why? /_showpageSqueak /showpage load def /showpage { gsave _showpageSqueak grestore } bind def - EPS files aren't supposed to mess with global drawing state settings. However, we do this: [ currenttransfer /exec cvx 1.2 /exp cvx ] cvx bind settransfer which appears (to me) to be changing the gamma. But what happens if you have several of these .EPS files in a single document? Won't the transfer function then be changed by each one of these? And anyway, isn't the gamma *really* device-dependent? How would we know how much gamma correction to use if we don't know what devices they're viewing the original and the Postscript on? It's not like we can assume they're viewing the original on a Mac and printing on a LaserWriter, after all... - We don't provide a preview image for the EPS, which makes it harder to actually *use* the EPS files in something like a word processor. Has anyone done any work with the Postscript output recently? Thanks, Ned

4 3

Jump to page: