The collected works of hamei - Page 65

uunix wrote: I have now officially run out of space in my house!

Build a shed to go with the loft. Then you can start a company, "Shed & Loft" :P
The time has come for someone to put his foot down ...
robespierre wrote: TrueType was solely created to get around Adobe's patent on bezier spline graphics. It never had a technical reason.

<insert nice discussion here about how much companies actually believe in the "imaginary property" myth :D >
there are a lot of good fonts out there that aren't Adobe.

I'm sure ... just happen to have a ton of Adobe fonts, and they are pretty nice. Also pretty happy with the way things are going - have been successful in re-converting otf's to pfa's (only butcher boys click to their horses), then finding the list of package numbers for the various adobe fonts, then downloading the afm's for them, then the rather complex rites to install in Irix ... but the end result is good. <fontview> works great, just need to find the dev headers for DPS now.

The deeper you get into this, the stranger it becomes. Fonts are never going to look wonderful on-screen with the monitor I am using - it's got not-square pixels. Graphics are super but text is fubar. (Why that would be I have no idear either. Shouldn't graphics want square pixels too ?) But pdf's look excellent. And they look excellent on the Winders box. Viewing the fonts on Winders, they all look the same - crappy. But put them into a pdf and view it, you can see all the little features that separate the good stuffe from the crappe. Really good fonts do make a difference. You would think, "Okay, it's the display engine of the operating system" but then why can pdf's look so much better with the exact same fonts ? Unless Windows is doing behind-your-back substitution. In many cases Irix does, for sure. If it comes across a bitmapped font first with the same name (which DPS requires), then that's what it'll toss on-screen. Which is okay 'cuz we have slow cpu's but .....

Maybe need to rework the bitmap fonts some day ... but quite happy with DPS. And now understand why they ditched Impressario - it's display postscript. Oooh ! Oooh ! Adobe charges money for that !

Yeah well, you want to charge $500 for a $29.95 Adaptec card but think Adobe should get zero ? So we get stuck with that CUPS pile of crap ? Fuck you, SGI.
Juliet ! the dice were loaded from the start ...
GIJoe wrote: the one shown is in pretty bad shape btw. also, you'd want the space-mouse, not the -ball i think. the latter is just plastic, on the flimsy side and puts extra stress on your forearm because when pulling the ball up on Z axis it is so light that you constantly have to fight the base to stay put. no such issue with the mouse which is much heavier (i used both, obviously).

I used this one
spacey.jpg
spacey.jpg (12.91 KiB) Viewed 348 times

with an Indigo, now have a 5000-series which works basically the same. I don't have any problems with the unit rising off the desk but don't use z much, more twisting and rolling in x and y. You can swap axes around but then, everyone has their own preferences and use patterns, so ....

I did see a photo somewhere of an actual SGI space mouse, that would be cool but not worth any more money unless you are a collector.

Robespierre - I think all the changes since the very first one were either to

1) cheapen it to make more money
2) jack up sales through marketing schmutz

the model 2003 seemed just as good as the model 5000.

And the guys there are pricks. Some guy on their forum with an old HP was asking for the driver, the company rep told him to go pound salt. "We don't support those old units, buy a new one." Like it would cost them so much to keep a 50k file on their server. Or like they even have a serial-connected new one you could buy. Officially-designated rude, avaricious, ignorant jerks.
"all the leaves are brown and the sky is grey ..."
vishnu wrote: Illustrator won't start at all on systems using VPro graphics, it hangs before even getting the splash screen up...

beg to differ, monsewer :P


I had a similar problem on the O350 tho, but with PhotoShop. I am mistrusting the DPSNXagent thingy but who knows ...
Juliet ! the dice were loaded from the start ...
Trippynet wrote: Google's name won't be changing. What they've done is create a new holding company called Alphabet to take advantage of various tax dodges they bought from Congress so the company doesn't have to pay 35% income taxes like normal human beings and the other worthless 'little people'.


Fixed that for you :P
Juliet ! the dice were loaded from the start ...
robespierre wrote: I do remember that a lot of people preferred the "Cadman", which was sort of like the Space Mouse but much flatter and lower to the desk. Kind of like people who prefer smaller mice for ergonomic reasons.

Speaking of ergonomics, I dunno ... I've always found a spherical shape to be more instinctive, a better, more natural fit to the hand ...

"all the leaves are brown and the sky is grey ..."
wenp wrote: Antialiasing on Windows ... fonts on the Mac have a nicer shape but tend to look fuzzy.

Guess I shoulda asked you first :) It's even worse than this, really. Windows is the easiest to look at uninstalled fonts - just click the file, very simple. But that doesn't tell you anything, they are so nondescript on Windows that you can barely tell the difference between Gill Sans and Zapf Chancery. Loonix has nothing, in Irix you have to install the fonts before you can see them - not a massive undertaking but still a chore. And the monitor I am using at the moment has non-square pixels, so that's no good either. Plus, fifty cents says that X doesn't display fonts all that well anyhow.

In real life (tm), even though the marketdroids have been chanting "wysiwyg !!" for twenty years, it ain't. Ain't by any stretch of the imagination.

I am guessing there are some typesetting machines that really do display what will be printed ?

For now, easiest to install - exstall is Windows, so install a font of interest, drag a paragraph into word, print it to a paper printer as well as a ps-to-pdf, and look at it as a whole. Lots of times a beautiful "f" doesn't translate into the look you want on a complete page.

Then the Chosen Few go into /usr/lib/DPS/outline/base ...

Adobe Reader uses its own display engine, which treats text more like a Mac. If I have some cheap fonts that aren't displaying well on Windows, one workaround is to put them in a PDF and do a screen capture of the display.

XPDF also looks better than the desktop display, even with rectangular pixels. I wonder how they do that ? But as long as the end result is what I want, I can live with it. Probably have to, unlikely that X is going to re-write their display engine to please me.

Learned a few things along the way so far - one is, it's pretty easy to edit the pfa's and afm's to change the font name. AdobeGaramond I don't mind, but ITCLTMTTimelyNewHeavenetickishProWithExtraGlyphs(c)1989-1993-1997-2003-ExtendedEditionBuyOnlineForaGoodTimeAnyTime is ridiculous. It's just a few places to edit the font name and running makepsres again. And while you're there, you can remove the copyright all rights reserved statement. Piss on Imaginary Property :D In fact, I've been replacing (c) Adobe with (d) designed by Carol Twombly :P
Juliet ! the dice were loaded from the start ...
jimmer wrote: And because the interweb provideth:

http://www.thebookdesigner.com/2010/03/ ... -designer/

Enjoy :)

Grazie, Senor Jimmer Sir, Esq :D Because Great Mindes Thinke Alikethe, that's one I saw. Here's another that is more Eurocentric (he says, struggling to find a US designer on the site) ... umm ...

https://www.fontshop.com/families/morris-sans

This one is clunkier to use tho. And Ms Twombly is cool. I am developing a theory that all the best typefaces are designed by kooks :P

Still doesn't solve the "text looks different in small doses" problem tho ... some pages at Door #2 give a big enough layout that you can get a better idea. More or less ... printing a paper page still might be best :(

I just discovered something else that may be useful to a future Irixxer ... PhotoShop and Illustrator both use the Type1 fonts that live under /usr/lib/DPS. But Framemaker , from the same manufacturer, only uses its own fonts ! If you want FM to have a wider selection of fonts, you get to jump through some flaming hoops. Woof ! Woof !

Not sure what to think about that :(


While I was in there I changed New Century Schoolbook back to Century Schoolbook and changed the copyright notice to ATF, 1919. Come get me, Adobe, you intellectual property thieves. Where's the SBA when you really need them ? :P


+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

edit : may as well stick it here, just in case some future historian discovers the search button ... might help some people save a little time.


Fonts in Pre-23 Irix :

Bitmap fonts, pretty much the same as standard X. Even real similar to Loonix.

I did make one little change that may or may not speed things up a tad - we have very slow cpu's so the little stuff makes a difference ? The font path searches 100dpi, 75dpi, misc, Type1, Speedo, and CID. I have nothing useful in half those. So I changed the name of 75dpi to 75dpi-bak (never can tell when you may need it), created a replacement 75dpi folder and put a fonts.dir file in it with just the one line "0". Without that fonts.dir X will not start. Don't ask how I know that. Now it only searches the folders with the fonts I actually use. 5 milliseconds but they add up :D

One interesting side effect of this change was that some system fonts changed. Apparently all the bitmap fonts don't exist in both 75 and 100 dpi versions. So while you may think you are using 100 dpi bitmaps, maybe you aren't. 200 dpi monitor, 75 dpi fonts. Mmm, good :roll:


Outline fonts, ha ! slightly different. In Irix, the real font files go under /usr/lib/DPS/outline/base and the metrics go in /usr/lib/DPS/AFM. DPS = Display Postscript.

To add new scalable fonts, they need to be Type1 and pfa format. The font files go as above but the names have to be the real font name, no extension. Real font name can be found by < grep /FontName font file's visible name >. The inner name and the outer name have to match. The metrics files go under /usr/lib/DPS/AFM, straight text files, no extension, name matches the file in /usr/lib/DPS/outline/base. Then a < makepsres > operation will have the fonts usable by any Display PostScript application. e.g., Illustrator and Photoshop. Framemaker should but it apparently only uses its own fonts. There is a process to add those to Maker but that's at the discretion of the user.

At this moment, your DPS applications can use the scalable fonts but nothing else can. If that's all you want, stop here.

To add the Type1's to X so that everything else can use them, Irix shadows the real files to /usr/lib/X11/fonts/Type1 and adds a .pfa extension. There is a script to do this automatically (forget the name but it's something like < xtype1 > or you can do it manually. Then the usual < mkfontdir > and < xset fp rehash > apply. But Ha ! there's a gotcha. Irix has a file "ps2xlfd " under /usr/lib/X11/fonts. This maps the PostScript names to XLFD names. Without this, you can see the font names in xfontsel but if you try to actually use them, kaboom ! Outta X you go. How rude ! I believe there's a script to create this file as well but for just a few fonts, I add them manually. Or in the case of Rock, Cave, and Amie removal, I delete them manually. Who in the heck put those abortions into a professional-grade workstation ? Was this an early sign of how SGI was losing it ?

Another small thing I discovered by experimentation (fools rush in ...) the xlfd does not have to be exactly what the font thinks it is. It actually just maps what the user sees to a specific font file. In general, Adobe steals everyone else's imaginary property and claims it for themselves. In the xlfd you can change the foundry (for example) to whatever you want. X doesn't seem to care. For instance, I redid all my "New" Century Schoolbook to Century Schoolbook and the foundry to American Type Founders, who actually created the typeface. You can safely remove all the extraneous "MT" and "LT" and other bullshit from the fontnames (in xlfd) as well.

To go one step deeper ... in the Type1 files, you can easily change the font names to something more reasonable. I don't need or want "Pro", "Standard" or "Capt'n Billy's Whizz-bang" in all my font names. It's stupid and makes all the drop-down lists as wide as the Mississippi. Emma come-a once, then I come-a ... And the type "foundries" are no longer foundries, they are just shysters sucking at mommy's titty, collecting from their trust funds while waving a "we're Job Creators !" flag. To hell with them ... so let's Nedit back into the /usr/lib/DPS/outline/base font files and replace the (c) 2003 Adobe Systems with (c) 1919 Mathew Benton, American Type Founders. Or even better, (c) 1989 Adobe Systems can be replaced with (c) 1560 Claude Garamont. Let's give the credit to the people who did the work :D

I know, wasted an hour on this. But it gives me some pleasure. I dislike hypocrites.

Don't forget to also change the afm's and redo all the supporting files, xset fp rehash, all that.

Nice fonts well-organized - it's like having a six-pack under the shaker.

If I got some of this wrong, corrections are welcome. Okay, not exactly welcome :oops: but necessary anyhow. Bad information is the bane of our world, so much total bullshit out there :roll:

Also just discovered Herman Zapf died last month. Sad :( Let's have a moment of silence for our dingbats ...
Juliet ! the dice were loaded from the start ...
Krokodil wrote: That is one advantage of MGRAS hardware, is that it supports a fairly good set of resolutions on either CRT or LCD's at standard refresh rates.

Another advantage, if you want to play with video, is that most of the video options work much more seamlessly with Mardi Gras. In fact, some of them won't work at all with VPro.
Juliet ! the dice were loaded from the start ...
wenp wrote: I don't work in printing, so I have no direct experience with this, but I hear frequent mention of the color issue from graphic artists commenting on GIMP, Inkscape, Scribus, etc. Are there any open source tools that handle color to industry standards?

Even before you get to the application level, you're screwed. Loonix has lcms and lcms2 which are supposed to do color management but ... the most basic step in color management is that your monitor has to match a standard. If what you are looking at is off, then it will obviously print "off".

(If you are doing the printing yourself, then you obviously also have to profile the printer. But commercial print shops are supposed to do this as a matter of course.)

Windows (and I am sure Mac) have profilometers that you drop over the monitor, then they tell the computer to display "red 3" (for example), then they compare the red 3 they see with what red 3 should be, then compensate for that with a profile that's loaded at startup.

Irix does have that but it's obscure. I'm still looking for an older profilometer that works with Irix. The 1600SW w/FPA on O2 came with that but the hardware doesn't work with any other monitor :(

But Loonix, I've never seen anything like that. If you can't even profile the monitor, where are you ? Who cares what the apps do, you're working in the dark from the very start.

One way around it would be, there are now some monitors that can profile themselves. But they are $$$$$$$$ !! That would remove operating system support from the equation, though.

btw, I've never been able to get Scribus or Inkscape to do anything except crash. My hat is off to anyone who can actually get something worthwhile out of them.
Juliet ! the dice were loaded from the start ...
jimmer wrote: The opensource toolset/chain is well-suited to on-screen and non colour critical work. it's just a bit of a mess when you need colour accuracy.

The discussion of color management on Loonix sites really seems over-complex to me. There's a ton of discussion about applications using ICC profiles, &c &c. But ... why ?

The printer is the output interface to the real world. You need to know that when you tell a printer Red #3, you'll get Red #3.

The monitor is the input interface from the world. When a human looks on-screen, if he wants Red #3, then he adjusts the color he is creating to achieve that, yes ? As long as the monitor and printer both create a physical Red #3 which is the same, why add all that other crap ? The middle parts will take care of themselves.

If we were trying to achieve colors-by-the-numbers then sure. But we aren't. It's ALL decided by the human creating the graphic. So if what he sees is what he gets, the middle is incompetent, irrelevant, and immaterial.

Seems like if you could just profile the monitor in Loonix then drop in a compensation table, you'd be 90% of the way there. X-Rite, she don't wanna play with that scruffy little hooligan :(

when I get home from the Carnival I'll give Scribus and Inkscape a go see if I can get something 'worthwhile' out of them.

Oh great. Now I'm gonna have to buy a hat. Can I share it between you ?

Seriously, if you guys can make those things get as far as drawing three lines without crashing, I'm impressed. Especially Scribbles :D
Juliet ! the dice were loaded from the start ...
duck wrote: Perhaps if it's really stacked, it might cause a problem?

Hard to know without testing ... maybe give it a try and let us know ?
Juliet ! the dice were loaded from the start ...
Black Cardinal wrote: ... once you try to use a different output device or share your file with someone else the color would break.

This is where I think the error lies.

If your monitor is profiled so that red #3 is actually red #3, then whatever application you use will be creating red #3 for viewing. However the application creates it, it will be adjusted to being an actual red #3 by virtue of the human sitting in front of the screen. We are the de facto colorimeters when creating the graphic :D

Of course in real world terms it won't be Absolute Red #3 because humans can't do that. But that isn't what we want anyway. The point of color management is to get the color out that the human put in. A corrected monitor would make that happen because the human would tweak the color to get what he wants.

So if the monitor is corrected and the printer is corrected, the stuff in the middle doesn't matter. It will get adjusted to generate the color the human wants by the human at creation-time. Not an absolute numerical color measured by the frequency of the lightwave, the color that the graphic artist wants to see !

That's the point of it all.

If you use a different input or output device, it should also be corrected. If it's not, then no matter what you do it will be wrong. Same with sharing files.

Also, it's not possible no matter what you do to get the same output on everything. Shiny monitor vs matte, high-resolution vs low, inks vs light, laser vs inkjet vs dye-sub, they are all different. ICC profiles can't make a toothbrush out of a turnip. It's a waste of time to try.


Doubtless, correcting every single part would be conceptually superior. But I think of this as the difference between a Porsche and a Scat VW. The 911 engine is beautifully made but has 4,000 extra parts. While the Porsche was sitting on the bench getting its valves adjusted (6 hour job), the Scat was winning races. Lots of races.

I'm betting you can do 95% of what needs to be done with just a corrected monitor and printer. The main trouble is, for fossysoft, that X-Rite doesn't want to play with Loonies. Another guess is, the internals to the hobbyist-grade colorimeters are so simple that if the knowledge of how they work got out, there'd be five companies in China making these things for $35 each. In fact, I'm sure of it because if X-Rite sells them for $150, dollars to donuts they are buying them in China for $35. Or less. They should be afraid.
Juliet ! the dice were loaded from the start ...
Black Cardinal wrote: Agreed. But if you don't do this correction with ICC profiles, then you still have to do it with some equivalent mapping mechanism. Why not stick with the standard?

I don't have a problem with ICC profiles :) but here is where I see the train going off the tracks ...

Real professionals already know what they are doing and they have the tools to do it with. Lustre is, what, $150,000 USD ? So we're not really talking about Lucasfilm.

A few years ago we had a lot of grief with printers, maybe similar to what jimmer started the thread over. Only worse ... in China, you can spend several days getting your stuff exactly how you want it, then you take it to the printer and the first thing they do is open CorelDraw and drag all your carefully laid out graphics into the wrong program with the wrong fonts at all the wrong sizes. Then they print that and expect you to take it with a smile. Sometimes they even 'correct' your spelling. Too bad they can't speak or spell in English. Seriously.

We didn't buy a Xerox printer that's the size of a house because we wanted to look cool.

So I went through all the online stuff about color spaces and colorimeters and spygnaphomometers and other dandy stuff and we bought a Spyder 3. Profiled the monitor. Cool ! Used the ICC profile on the printer. Cool !

Except, it kinda wasn't. To actually get things to match we had to adjust by eye. And that's probably not 'right' but now what we see on-screen is now what we get from the printer (on the Windows box, cuz the Irix box is totally different and I am NOT going to make my Octane look like a peecee, but everyone else in the world uses peecee's, so there ya have it, the flaw in userland "color correction" right off. People like their monitors to look the way they like them to look, which ain't 'standard' so how is this going to work ?) .

And that's the point.

On most modern systems, when you use a spectrophotometer to measure your monitor or printer output and get correction values, what you are doing is creating a custom ICC profile for that device. Nobody who really cares about color accuracy trusts the default profiles for devices,

EXACTLY ! Which brings up another few points ...


1) the 'standard' ICC profiles for devices ... well, they don't work. Maybe on a brand new device but even there I have my doubts. Maybe on a standard high-end Eizo or NEC, but not on runofthemill Office Depot printers and monitors.

Which is what most people use, so ...

2) the devices people are using to create these profiles ... at the time, I read up on shit, the Spyder 3 was yay ! great ! cool ! wonderful ! so much better and more reliable than the Spyder 2 and the Huey is crap and the DTP-92 is so ooold ...

Yeah, right. Marketing marketing marketing. In fact, the Spyder 3 is kind of crap, now it's the Spyder 5 that's Wonderful ! so much better ! but in a year we'll hear that oh-oh, actually you need the Spyder 9 but in fact, I've seen a few charts where Luminous Landscape tested a series of these things, once they stuck in an antique Gretag Sinaloamometer or whatever its name was, the damn thing was third-best STILL out of all their devices but they didn't say a word about this. One thing about being old is, you get to recognize the same old shyster schtick once you've seen it about thirty times.

And THEN you discover that ALL colorimeters are really no good, no matter how expensive, the filters degrade over time. But the spectrophotometers are no good in the darker, low-light regimes.

In fact, the truth is none of the cheap units are worth a shit. Something I know as a fact from making parts is, if you can't measure it reliably and your measuring tools are not calibrated at least annualy, then everything you say is nothing but a joke.

Which pretty much describes the state of user-level color correction.

I read all these guys' comments in the photo bulletin boards and have to think, unless they pay the big bucks for a measuring unit, they are just pulling their puds.

And that's pretty much where Loonix is as well. Almost no one is going to pay real money for a pro-level spectrophotometer. Almost no one is going to have their colorimeters calibrated every six months.

If you are, then you already know what you're doing. Otherwise, all this talk of 'color-managed-workflow' and getting Loonix to use ICC profiles for every program and printer they 'support' is just a giant circle jerk. It's Yet Another 68,000 Dependencies that don't do anything (except get in the way.)


btw, discovered that OptiCal had an Irix (and Loonix) binary and supports the Minolta CA-100. Those are available fairly cheap used, now we're talkin an instrument that might actually measure. After you get it recalibrated, anyhow :D


No, I'm not trying to say that color management is a fraud. But the Loonix implementation of it is a joke and from History, whatever they do next with it will be even worse, e.g. GTK3.

jimmer wrote: Have given up on getting scribus to work. The neko packages from current dont run on my system and the new scribus needs versions of qt that wont compile on our beloved 20 yr old machines. Oh well.

My experience as well :( Also tried it on Windows. Inkscape, too. If they can't make it run without a bunch of pointless toys, I'm not going to screw with it. Gtk2, gcc-isms, shithub, qt, gag me with a spoon. More of the same pointless stupid crap just because it's kewl. Fuck 'em.
Juliet ! the dice were loaded from the start ...
ClassicHasClass wrote: No, not particularly. It's really just high grade radiator coolant (Delphi A2, to be exact; Delphi 151 should be equivalent).

Should run straight water. Ethylene glycol is bad for the world and doesn't do anything good unless your house gets below 32* F. :D Anti-freeze has absolutely no benefits in transferring heat over straight water. Since the blocks on cpu's are not cast iron, I don't see any advantages in rust-inhibiting, either. Copper doesn't rust much.

Higher performance coolants can be substituted if desired.

There are no "higher-performance coolants." Water is just as good as the best of them. It just has the small drawback of freezing at 32* F.

No racecars run coolant. No race bikes, either. It's not allowed, and it's not a problem. When a G5 makes 600 hp I'd start to get concerned about the 'performance' of the coolant.

Shouldn't use it. It's bad for the world. Ethylene glycol is not good for humans or small dogs.
Juliet ! the dice were loaded from the start ...
mapesdhs wrote: it's so old now that I can't use my Fuel for a lot of the web stuff I do these days ...

Surfing Ashley Madison ? :P
Juliet ! the dice were loaded from the start ...
Moving forward on the fonts project, everything seems good except for one small thing ...

Added a new Type1 font, it works perfectly in DPS apps (PhotoShop, Illustrator, etc.)

I then added it to X under /usr/lib/X11/fonts/Type1. Manually added an entry to fonts.scale then did mkfontdir to create a new fonts.dir. Also manually added the font to ps2xlfd_map. Maybe it's wrong but looks exactly the same as the other entries. Then as root xset fp rehash.

Now the new font shows up in xfontsel but if I select it, I get kicked out of X. I have a vague recollection that DPS required at least one bitmap font which matches the scalable font, for some reason. Is this an X requirement, is my memory bad, or did I just screw up somewhere ? Have double-checked everything, the font is listed correctly everywhere (as far as I can see), it works fine under DPS, but under X kerplowie. Do you need to add a fonts.alias with some specified scale to X scalable fonts, or am I blowing it some other way ?



edit: for the record : had to be a bad font. I just dragged am OS/2 pfb font over, pfb2pfa-ed it, put it in the /usr/lib/X11/fonts/Type1 directory, added it to fonts.scale by hand, did < mkfontdir > then < xset fp rehash > and viola, shows up in xfontsel perfectly, even without an afm file and no bitmap accompaniment.

So must have been a problem with the font itself. yay.
I never thought that a fat man's face would ever look so sweet ...
mapesdhs wrote: Online banking ...


So may the outward shows be least themselves - the world is still deceived with ornament.

In law, what plea so tainted and corrupt but, being seasoned with a gracious voice, obscures the show of evil?

In religion, what damned error but some sober brow will bless it and approve it with a text, hiding the grossness with fair ornament?

There is no vice so simple but assumes some mark of virtue on his outward parts.

How many cowards, whose hearts are all as false as stairs of sand, wear yet upon their chins the beards of Hercules and frowning Mars; who, inward search'd, have livers white as milk ?

And these assume but valour's excrement to render them redoubted!

Look on beauty and you shall see 'tis purchased by the weight which therein works a miracle in nature, making them lightest that wear most of it.

So are those crisped snaky golden locks which make such wanton gambols with the wind upon supposed fairness, often known
to be the dowry of a second head, the skull that bred them in the sepulchre.

Thus ornament is but the guiled shore to a most dangerous sea, the beauteous scarf veiling an Indian beauty -

In a word, the seeming truth which cunning times put on to entrap the wisest.


:P
Juliet ! the dice were loaded from the start ...
nyef wrote:
Black Cardinal wrote: Nobody who really cares about color accuracy trusts the default profiles for devices, they measure and create a custom one for each set of variables.

It's worse than that. Devices change as they age, and possibly with environmental conditions, so the profiles need to be updated periodically (annually? bi-annually? not sure what the actual period is, and it probably depends on how much you care about color accuracy).

On Loonix, it's doube-triple-quadruple hopeless. I haven't looked into this for a little while, did a quick refresher. Argyll seems to have come along a ways, nice. Then I went here ...

http://dispcalgui.hoech.net/#runsource

fuck. That's all I can say, just "fuck". What a total crock of shit.

"running from source" ... gag me with a spoon, there is no source, it's an effing python script.

dispcal dipshit wrote:
Running directly from source

After satisfying all additional requirements for using the source code, you can simply run any of the included .pyw files from a terminal, e.g. python2 dispcalGUI.pyw, or install the software so you can access it via your desktop's application menu with python2 setup.py install. Run python2 setup.py --help to view available options.

One-time setup instructions for source code checked out from SVN:

Run python2 setup.py to create the version file so you don't see the update popup at launch.

If the pre-compiled extension module that is included in the sources does not work for you (in that case you'll notice that the movable measurement window's size does not closely match the size of the borderless window generated by Argyll CMS during display measurements) or you want to re-build it unconditionally, run python2 setup.py build_ext -i to re-build it from scratch (you need to satisfy the requirements for compiling the C extension module first).

It gets worse ...
moronic shitforbrains so-called developer wrote: Starting with dispcalGUI 0.2.5b, you can use standard distutils/setuptools commands with setup.py to build, install, and create packages. sudo python setup.py install will compile the extension modules and do a standard installation. Run python setup.py --help or python setup.py --help-commands for more information. A few additional commands and options which are not part of distutils or setuptools (and thus do not appear in the help) are also available:
Additional setup commands

0install
Create/update 0install feeds and create Mac OS X application bundles to run those feeds.
appdata
Create/update AppData file.
bdist_appdmg (Mac OS X only)
Creates a DMG of previously created (by the py2app or bdist_standalone commands) application bundles, or if used together with the 0install command.
bdist_deb (Linux/Debian-based)
Create an installable Debian (.deb) package, much like the standard distutils command bdist_rpm for RPM packages. Prerequisites: You first need to install alien and rpmdb, create a dummy RPM database via sudo rpmdb --initdb, then edit (or create from scratch) the setup.cfg (you can have a look at misc/setup.ubuntu9.cfg for a working example). Under Ubuntu, running utils/dist_ubuntu.sh will automatically use the correct setup.cfg. If you are using Ubuntu 11.04 or any other debian-based distribution which has Python 2.7 as default, you need to edit /usr/lib/python2.7/distutils/command/bdist_rpm.py, and change the line install_cmd = ('%s install -O1 --root=$RPM_BUILD_ROOT ' to install_cmd = ('%s install --root=$RPM_BUILD_ROOT ' by removing the -O1 flag. Also, you need to change /usr/lib/rpm/brp-compress to do nothing (e.g. change the file contents to exit 0, but don't forget to create a backup copy first) otherwise you will get errors when building.
bdist_lipa
Create a Listaller package.
bdist_pyi
An alternative to bdist_standalone, which uses PyInstaller instead of bbfreeze/py2app/py2exe.
bdist_standalone
Creates a standalone application that does not require a Python installation. Uses bbfreeze on Linux, py2app on Mac OS X and py2exe on Windows. setup.py will try and automatically download/install these packages for you if they are not yet installed and if not using the --use-distutils switch. Note: On Mac OS X, older versions of py2app (before 0.4) are not able to access files inside python “egg” files (which are basically ZIP-compressed folders). Setuptools, which is needed by py2app, will normally be installed in “egg” form, thus preventing those older py2app versions from accessing its contents. To fix this, you need to remove any installed setuptools-<version>-py<python-version>.egg files from your Python installation's site-packages directory (normally found under /Library/Frameworks/Python.framework/Versions/Current/lib). Then, run sudo python util/ez_setup.py -Z setuptools which will install setuptools unpacked, thus allowing py2app to acces all its files. This is no longer an issue with py2app 0.4 and later.
buildservice
Creates control files for openSUSE Build Service (also happens implicitly when invoking sdist).
finalize_msi (Windows only)
Adds icons and start menu shortcuts to the MSI installer previously created with bdist_msi. Successful MSI creation needs a patched msilib (additional information).
inno (Windows only)
Creates Inno Setup scripts which can be used to compile setup executables for standalone applications generated by the py2exe or bdist_standalone commands and for 0install.
purge
Removes the build and dispcalGUI.egg-info directories including their contents.
purge_dist
Removes the dist directory and its contents.
readme
Creates README.html by parsing misc/README.template.html and substituting placeholders like date and version numbers.
uninstall
Uninstalls the package. You can specify the same options as for the install command.

Additional setup options

--cfg=<name>
Use an alternate setup.cfg, e.g. tailored for a given Linux distribution. The original setup.cfg is backed up and restored afterwards. The alternate file must exist as misc/setup.<name>.cfg
-n, --dry-run
Don't actually do anything. Useful in combination with the uninstall command to see which files would be removed.
--skip-instrument-configuration-files
Skip installation of udev rules and hotplug scripts.
--skip-postinstall
Skip post-installation on Linux (an entry in the desktop menu will still be created, but may not become visible until logging out and back in or rebooting) and Windows (no shortcuts in the start menu will be created at all).
-stability=stable|testing|developer|buggy|insecure
Set the stability for the implementation that is added/updated via the 0install command.
--use-distutils
Force setup to use distutils (default) instead of setuptools. This is useful in combination with the bdist* commands, because it will avoid an artificial dependency on setuptools. This is actually a switch, use it once and the choice is remembered until you specify the --use-setuptools switch (see next paragraph).
--use-setuptools
Force setup to try and use setuptools instead of distutils. This is actually a switch, use it once and the choice is remembered until you specify the --use-distutils switch (see above).


I used to think Windows was bad. Dispyguy, please take your ridiculous horseshit play-with-yourself useless crap and go away. Far away. Off the edge of the earth would be nice.

./configure, make, make install. It works. Try it some time.

Loonix. The breakfast of imbeciles.
Juliet ! the dice were loaded from the start ...
Pontus wrote: What I did was to take the original PSU fan and strap it on the outside of the box, just running power and tachometer cables to it. So it doesn't actually cool the computer, but it keeps L1 happy.

I ran the Fool for years with the environment monitoring turned off. Sounds bad but the Octane doesn't have it, so what the heck.
I never thought that a fat man's face would ever look so sweet ...
kurkosdr wrote: ... that "using it as a daily driver" is NOT a good idea if you don't have access to browser security fixes.

Why ? If you're not stupid enough to do online banking or keep photos of your mom screwing a German Shepherd on a computer connected to the Internet, what the heck do you have to lose ? If you take normal precautions, I can't see where a Solaris-user has anything to fear from an old browser.
Juliet ! the dice were loaded from the start ...
Rhodamine wrote: In my experience these things rarely get better and ultimately lead to some form of catastrophic failure

In this oddball case, this is a good sign. The death-march for Fuel power supplies is the irreplaceable cheap-ass little SGI chip that turns them on.

The power supply itself could explode, but as long as that little interface chip is okay there's probably a hundred dead Fuel power supplies to cannibalize. Heck, I had two myself I'd have contributed, but got tired of them cluttering the place up.
wrestle poodles and win ! ...
robespierre wrote: This might have something to do with the font problem also...

My problem with fonts, anyway, is opposite to this. They work perfect in Display Postscript apps but crash X. My DPS apps have not worked this well in years. Give that DPSNXAgent thingy the boot !

Gotta try installing a scalable font or two in just X and see what happens.
Juliet ! the dice were loaded from the start ...
uunix wrote: I know the type very well.

Yes, seems kind of cheesy. But otherwise those cables would most likely go into the dump, where the copper would be wasted. So it's actually a good thing for the world.

This doesn't happen much in China, since we have rag-and-bone pickers who scrounge through all the garbage looking for ten cents. US used to have that too but now y'all have expensive Federal and State programs instead. That's why California sales tax that used to be 4% is now 9%. You can support a lot of administrators and a few poor people with that 5% difference :D
Juliet ! the dice were loaded from the start ...
Vladio wrote: I, surprisingly, have no font issues. Okay, an occasional panic ...

Hmm. DPSNX ? Shouldn't get panics.
No one else drives two monitors?

Did that for quite a while but they were both on the same panel so it didn't matter. The dcd is two channels but only one head so you don't have the same kind of control you would over a dual-head setup. Plus Illustrious wasn't really written as an Irix application, it's a cheapass port of an Apple program, so ... you may have to just drag the menus where you like after they pop up.

This is where Inkscape should come in, you could actually fix it or get it fixed. But it's such an abortion that that's out of the question :(

You could start work on it tho, if you got bored :D
Juliet ! the dice were loaded from the start ...
Oops, sorry :oops: I just went back and read the whole thread ... it's not entirely an Illustrator problem.

I don't have that much help to offer but ran a dcd for a couple years, at least. You are not seeing normal behavior. I can't remember if the dialog boxes of which you speak always opened in the center or not - both my channels displayed on the same panel - but I am sure I could move them around. They did not "snap back to center" at all.

Zo, you have more than one problem. Your Illustrator problems (empty file dropdowns and so on ?) sound like real Illustrator problems.

But the system dialog boxes, you've got something wrong. They should move and resize quite happily all over the screen, and from screen to screen even with a dcd.

And you can set those to start up at a predefined location by using .Xdefaults. The dcd just thinks it's one big screen. Use xdpyinfo to find how big your display is, then xwininfo to find the -geometry data for the window you want to control (after you size it and put it where you want it). Then put that info into whatever you use to start the program or into your Xdefaults and bob's yer uncle.


@ robespierre : was (probably) a bad font. Tried a couple others from the ol' OS/2 stash, converted 'em from pfb2pfa and they work perfectly. But there's no afm's in X ?
Juliet ! the dice were loaded from the start ...
OKay, a little appendix, answer a few unasked-questions :

First, I never could find a Unix Loonix uninstalled-font viewer. Easiest way seems to be drag the font into Windows, print up a paragraph to file via a PostScript printer, turn it into a pdf and then look at it. Not lovely but it works. Viewing in Windows tells you nothing, on-screen display is only vaguely similar to what the typeface will really look like.

Second thing to know is, the process for installing scalable fonts in Irix is pretty reliable. If you get a font that refuses to work, suspect the font first. I wasted several hours at least because I was sure I was doing something wrong. The fact that the font works in DPS does not mean it will work in X.

A few things that are not in techpubs that I learned the hard way :

You don't have to put all your type1 fonts under /usr/lib/DPS/outline/base. You can split them into other directories. This command :

Code: Select all

/usr/bin/X11/makepsres -o /usr/lib/DPS/DPSFonts.upr /usr/lib/DPS/outline/base /usr/lib/DPS/AFM

can be run as

Code: Select all

/usr/bin/X11/makepsres -o /usr/lib/DPS/DPSFonts.upr
/usr/lib/DPS/outline/base /wherever-your-other-type1-fonts-live  /usr/lib/DPS/AFM

(all on one line)

and it will add the other directory full of font files to the DPSFonts.upr fontlist file. I just stuck all the afm's into the one directory. Couldn't think of any reason to split them up.

So if you want to organize into, for example, the base fonts which are loaded in PostScript printers, and all your cutesy-wutesy fonts somewhere else, the utilities will still work. The DPSFonts.upr file tells DPS where to look.

Adding to X :

No need for a makefontscale utility. This one was a pain in the ass. I searched and searched fruitlessly for something it turned out you don't need. There are a few makefontscales hanging around on the web but they don't work in Irix. But mirabile dictu, Irix comes with (don't know what subsystem, could be DPS or Impressario or something else) < type1xfonts > which not only shadows the DPS fonts into X, but it also creates the fonts.scale file. Whoo-oo ! Nice.

Sort of. If you have, say, two or three directories of fonts under /usr/lib/DPS/outline, < type1xfonts > will shadow the font files to the /usr/lib/X11/fonts/Type1 directory and simultaneously create the fonts.scale file. Per directory. Do < type1xfonts -t postscript-fontfile-directory -x x-fontfile-directory -e (if you want) .pfa (it will do that automatically tho so no need).

That shadows all the DPS fontfiles in that directory to X, adds the pfa extension, and writes a nice fonts.scale file. Unfortunately, if you already have a fonts.scale file in the X/fonts/Type1 directory, it just overwrites rather than appending.

To add more directories of fonts, first hide the existing fonts.scale, let < type1xfonts > create a new one, then just append the new one to the old one (and change the number at the top to match the number of listed fonts.)

Then run the normal X < mkfontdir > as root within that directory, < xset fp rehash > and bob's yer uncle.

Don't forget the ps2xld_map file or your type1's still won't work in X. That's easy tho, just snag the long font name from fonts.dir and add it to ps2xlfd_map.

You can change copyright notices and the foundry and font designers to give the credit where it is due.* But you have to do it manually, there's no automated Irix tool to do that. Yet :D

Why split up the Type1 fonts into multiple directories ? I was thinking that in Illustrator, maybe I wanted a bunch of goofy decorative fonts, a wider variety of choices, more sizes and artistic features. But in X, I don't want to have to scrounge through a list of 175 fonts just to find a clean serif for a note to Mom. And Framemaker doesn't seem to use the system fonts, so it would be easy to choose a subset of the available fonts to serve just to the Frame. Multiple directories makes it easy to choose which fonts are available to what programs.

Working okay now. 6.5.21 - 6.5.22 is good. Real good.


* Doing this got me thinking .... reading the Adobe brochures, Robert Slimbach spent hours and hours and dollars and dollars going over Claude Garamont's original texts to make as accurate a typeface as possible. Then he spent many more hours making it pretty and standard. Very nice !

So .... if I go to the library and take out Huckleberry Finn , can I make the pages pretty, turn it into a set of 'computer instructions" (like a text file ?) then copyright it as my own ? I can barely wait to start suing those bastards at Doubleday for infringing on my ! intellectual property !!!


A little additional entertainment :
Fonts F.A.Q. wrote: The (more or less) original point system (Didot) did have exactly 72 points to the inch. The catch is that it was the French imperial inch, somewhat longer than the English inch, and it went away in the French Revolution.

And we're (sort of) still using it :P There's more to that story but this was the funniest part.
Juliet ! the dice were loaded from the start ...
Axatax_ wrote: ftp.nekochan.net is prompting for a PW and won't accept anon connections. Anything change on this front?

Are you doing command-line ftp ? Mr Neko has the timeout set really short to dissuade roving internet bandits, so it's difficult to type your name fast enough. I use a graphical ftp, that's a single click instead of "anonym ... wait, does the y go first or second ? ... oops ! timed out !"
Vladio wrote: One caveat that I'm seeing is that Illustrator is clipping those 375 pixels off the left part of the left screen.

Even CS2 is rather peculiar to use. This OriginalMac-semitranslated-to-Irix version needs some work. I guess we're lucky to have anything.

I had high hopes for Inkscape at one time ... alas :(
Juliet ! the dice were loaded from the start ...
ClarusWorks wrote: I removed the card that was installed, and the machine still will not power on.

A fuel will definitely not power up without a working graphics card installed. btdt.

I'm not sure that having 5v means much. The big problem with fuel power supplies is not that the supply itself dies : there's a little SGI interface chip which dies, so the supply never gets a turn-on signal.

(That's a grossly simplified decription, I've forgotten the details, but essentially that's what happens. There's a thread here by Kubatysko describing replacing the fuel power supply with a standard one, he goes into the problem in depth.)
I never thought that a fat man's face would ever look so sweet ...
ClarusWorks wrote: Even if the main CPU won't power on, will the L1 come up without a graphics card?

That, I can't say. For some reason I wanted to try it headless. Fuel was running fine, I took out the graphics card, it was dead as a doornail. Put the graphics card back in, started right up.

I also had a V12 that went bad. Had the same behaviour.

So I'm about 99% sure they won't run without a graphics card.
I never thought that a fat man's face would ever look so sweet ...
ClarusWorks wrote: ... maybe the early NMB power supplies liked to cook themselves due to overcurrent on those rails.

The power supplies don't generally cook themselves. The stupid little interface chip dies and then you can't tell it to turn on.
I never thought that a fat man's face would ever look so sweet ...
ClarusWorks wrote: I can now confirm that a Fuel L1 will in fact come up with no CPU or graphics card attached :-)

That's good to know. The last time mine died, I could get nothing from the L1.

So it went in the garbage ....
ClarusWorks wrote: The chip that some people seem to have had fail in their NMB Fuel PSUs is a PIC microcontroller that the mystery fan signals as well as some other stuff are connected to. Actually powering on the PSU is just a matter of pulling the power on pin low, no chips involved.

How do you plan to do that ? With a toggle switch on the front ? To actually use it as a Fuel replacement you need to have that interace chip functioning. Or go through the entire Kubatysko hardware scenario, with faking out the tech signal, etc etc.

That's not exactly a direct replacement :(

also, it's not just in the nmb supply, its in all of them :(

It's a total pain in the ass :(

Knowing what's in the microcontroller would solve everything but that's apparently not so simple :(
I never thought that a fat man's face would ever look so sweet ...
Go for it :P Hope you are successful ....
I never thought that a fat man's face would ever look so sweet ...
ClarusWorks wrote: Sometimes the L1 comes up, sometimes it does not. Unplugging/replugging the AC cord from the power supply 2 or 3 times will eventually get it to come up.

On a Fuel ? This is common on O350's. Haven't heard of it on the fuel :(
I never thought that a fat man's face would ever look so sweet ...
Didn't see it in nekoware, did a search and only found one mention, so here it is ... doesn't need much,

Code: Select all

gort 2# ldd xpaint
libXaw.so.1  =>  /usr/lib/libXaw.so.1
libXmu.so  =>    /usr/lib/libXmu.so
libXt.so  =>     /usr/lib/libXt.so
libXext.so  =>   /usr/lib/libXext.so
libX11.so.1  =>  /usr/lib/libX11.so.1
libm.so  =>      /usr/lib/libm.so
libc.so.1  =>    /usr/lib/libc.so.1
libgen.so  =>    /usr/lib/libgen.so

should run on any 6.5 machine, maybe some earlier ones ? It's a really simple bitmap editor but kinda useful and not too ugly.

edit : i'm shocked at how capable this is. For a paint program that's under one megabyte, it's darn good ... not a PShop CS2 but quite useful ! (I gotta get the tablet hooked up again ...)

hey, ho, way to go, Ohio ...
commodorejohn wrote: Yeah, the interface is a bit janky ....

First impression is, it's fairly ugly. And the Athena scroll bars suck.

But it's laid out really well and the window with the icons is tits. Way nicer to use than the Photoshop/Illustrator layout. And all the icons make sense.

Maybe the newer version will read jpegs and pngs ... have to go look. I'm really kind of shocked at how good this thing is.
hey, ho, way to go, Ohio ...
jimmer wrote: ... have decided to try and use as much as possible of the default software that IRIX 6.5.30 provides. So I'm currently using the default Ksh as my shell rather than trusty old GNU Bash.

Umm, that may be going to extremes ... a shell is just a utility, and if you are used to one that you like, changing a tool you use all the time for something you dislike might not be a great idea ?

Getting rid of six layers of fonts that don't so anything is one thing, but a shell doesn't really interfere with the Irix Ambience (imo) ...

And I dislike bash, too, so not just saying that to be nice.

if you drag gcc into this tho, you're disowned :P
Juliet ! the dice were loaded from the start ...
okay, sports fans ... xpaint was a surprise, it seems quite useful. The Athena scroll bars are not lovely but otherwise, it's maybe as good as Photoshop 3 ?

Anyway, the biggest flaw with it is, the two most common graphics formats are not supported in 2.1.1 Luckily (maybe) other people have continued with xpaint, so newer versions will work on jpegs and png's without conversion.

Looking through the release notes, lots of things fixed (and some screwed up) along the way but at 2.8.16 they forced inclusion of fontconfig. So I figured I'd try 2.8.15. Maybe can butcher the newer ones to get rid of that but for now, this'd be okay.

Everything went lovely until

Code: Select all

cc-1020 cc: ERROR File - fatBitsEdit.c, Line = 781
The identifier "XK_Escape" is undefined

case XK_Escape:

I think this is a key press ? Several C files include this as well as XK_UP, XK_LEFT, &c &c.

edit: Okay, "fixed" the above by putting

#include < X11/keysym.h >
#include < X11/keysymdef.h >

in the Fatbitsthingy.c file and all the others with similar code. Is that correct ?

This next one looks to be less cooperative tho :(

Code: Select all

cc-1515 cc: ERROR File = fileBrowser.c,  Line = 1701
A value of type "int" cannot be assigned to an entity of type "char *"

name_format = index(msgText[IMAGE_FORMATS+j], ' ');


One would think this type of thing would be universal in the language, independent of the compiler ?
Juliet ! the dice were loaded from the start ...
vishnu wrote: Link to the source code? Browsing the CVS repo of the version at http://sf-xpaint.cvs.sourceforge.net/ there is no file fileBrowser.c, that I can see... :|

Here ya go ...
filebrowser.c.tar.gz
(11.77 KiB) Downloaded 3 times


This is 2.8.15, not what's in cvs. They went kinda Looney after 2.8.15. I'm thinking maybe can backport the good parts (if there are any) from the newer one later on. But first have to get it to build ....

this'd be pretty hot in Irix Motif (hint hint :P )
Juliet ! the dice were loaded from the start ...