World: r3wp

Anyway I rambo'ed it

Does freetype support also imply type 1 font support?

From the FreeType site:
#

By default, FreeType 2 supports the following font formats.

    * TrueType fonts (and collections)
    * Type 1 fonts
    * CID-keyed Type 1 fonts
    * CFF fonts
    * OpenType fonts (both TrueType and CFF variants)
    * SFNT-based bitmap fonts
    * X11 PCF fonts
    * Windows FNT fonts
    * BDF fonts (including anti-aliased ones)
    * PFR fonts
    * Type 42 fonts (limited support)

so, View will be able to use them?

So I guess all this should be possible to load using Rebol on Linux.

(but I haven' t tested all those font formats, just ttf)

It would be good to test the standard PS type 1 fonts

they normally come with the ghostscript install

I can test it if you point me to some free font to download.

most Linux builds have ghostscript installed with the PD type 1 fonts

let me check...

ah, found /gsfonts dir in my distro...will test some font from it 
in a minute...

yes, the PS type 1 fonts works ok for me here.

That's neat.

What distro are you using?

Mepis Linux. Well, Freetype2 is doing all the hard work for us here 
;)

Are the Debian builds much newer than the other Linux builds?

The Debian View has the freetype library, but the libc6 build does 
not.

Yes, it looks so. AFAIK I'm using the Debian version here.

So, I should send feeback to Carl and ask him to put freetype2 support 
in all Linux builds and the sdk.

It looks only Debian,Ubuntu and OBSD beta versions should have this 
feature.

Yes, I think that's the best way to let Carl know.

Ok.

there are separate downloads for Debian, Libc6, and  Ubuntu .. yet 
the same Linux enface supports all of them?

Sorry, don't know if some enface supports this. But I would say no. 
The FT2 support was only build in the separate beta releases.

I mean, the one enface for linux is able to build something that 
runs on Debian and Fedora.

Yet, there are separate downloads for these for View.

Graham, the needs for different builds on different distros only 
comes when you start requiring libs such as freetype, and find out 
that each distro is different.

it may be possible that one of the builds will work on all distros 
provided some lib symlinking.

it seems encap does not like directories with spaces in the name

Carl just responded to my feedback asking which distros I want to 
use .. so that is a good sign?

not necessarily...

implying that specific distros need specific support?

probably specific series of distros. some distros use different ways 
of handling configuration, installation and some distros are changing 
the library versions constantly.

anyone tried replacing the program icon in an encapped app? I just 
get a compression error when trying to open the app after the icon 
has been replaced.

I used reshacker as recommended in the docs.

Does this help: http://www.dobeash.com/RebGUI/cookbook.html#section-2

when trying to do it manually, I get the compression error. if I 
try it with scripting, I just get "invalid command" in the reshacker 
log. is it illegal to provide full path to the executable?

hmm... should try a different icon.

Paths are fine, just need to be fully qualified local (not REBOL). 
Key is to ensure that after replacing icons they are in the same 
order and have the same dimensions and depths as before. You can 
use reshacker to do a before and after check.


The example I use in the link above has everything in the same directory. 
Get that working first before worrying about paths.

the icon I used had only one 16x16 icon. that's probably why it didn't 
work

it works now for the manual one. now to get the scripting part to 
work.

found the error. thanks :-)

not so much luck with changing the file version though...

Key there is to keep it as a 4-part tuple.

found out... seems to work now

basically the size of the .ico file (in bytes) *must* match exactly 
the built in one. which means that you need same color depth, size 
etc.

you do have to fiddle quite a bit, but it works. I wish the SDK docs 
mentioned a bit more about this. it would reduce the amount of fiddling 
:-)

I wish The encaps would use real resources for the code, so that 
we would not have to fiddle in the first place.  and we would also 
be able to use PATH env variables to launch encapped scripts

yes, if it worked internally, maybe it could be possible to produce 
windows builds on a linux/OSX machine?