[rescue] Sun Kit Needed for EE Student Here

Don Y dgy at DakotaCom.Net
Sat May 13 13:21:00 CDT 2006


Charles Shannon Hendrix wrote:
> Thu, 11 May 2006 @ 08:02 -0700, Don Y said:
> 
>>> I was just curious. I haven't had one for awhile now.
>> Though, having said that, I recall building an Xrender
>> *package* (as a dependancy for <mumblemumble>)...
> 
> I have not quite figured out how that can work, since XRender uses the
> local GPU for doing the heavy work.

No idea.  It could be this is all done client side and bitmaps
just shipped over...

> It won't be long before X will be sitting on top of OpenGL. There are now two
> methods competing.
> 
>> The only horrendous font issues I found on the X terminals
>> (which is where I spend all my time) was trying to support
>> CDE with bad font matches (solved by copying Sun's fonts onto
>> my font server)
> 
> If I view documentation for non-trivial amounts of time, like a PDF
> file, the fuzzy fonts really start bothering my eyes.

I don't "read" documentation on-line.  :-(  I guess just a
generational thing (?) -- I want to hold paper in my hands
when "reading".

Of course, I have no problem *preparing* documentation -- since
I usually am working in a very small portion of the page and
can magnify a single column to fill a 21" monitor (makes viewing
easier -- especially if you are pasting/positioning callouts onto
illustrations, etc.).

> Other problems I've had are matching screen fonts to output fonts, which
> modern X and things like CUPs has almost eliminated completely.

Yup.  That's why I have *all* of my fonts on a font server.
Too bad Windows can't directly benefit from that approach...
instead, I have to have a copy on the Windows machine as well.

>>> I spent most of my time in terminal windows too, and that's specifically
>>> why I use pixpixel rendering for fonts.
>> Oh.  I find I can use very small fonts without any problems.
>> But, they are just *plain* (unadorned) fonts.  No other
>> attributes applied (italic, bold, etc.).  E.g., emacs doesn't
>> fare well when it wants to syntax hilight...
> 
> I have a hard time finding a font that I like for programming.  
> 
> The best programming fonts I have found are too small for my 1600x1200 screen.
> 
> I want certain things in a programming font at a minimum:
> 
> 	- zeros are slashed
> 	- things like 1 and l are distinct
> 	- no serifs
> 	- not jagged or fuzzy
> 	- works in all the programs I need to use

I'm not as fussy.  :>  As long as my zeroes are distinguishable
from oh's (either slashed, slimmer or "tapered") I'm happy.
I prefer serif fonts (sans serif are harder on the eyes -- hence
the reason you find most document printed with serif fonts
and sans serif for headings, etc.)

My "stock" session has two 80x25 windows and a single 80x66,
none of which overlap.  This gives me a fair amount of root
window to call up applications (click on root to pull up
menu).  An emacs window usually sits on top of things but is
easily cycled up/down when I need access to the other xterms.
Iconify xterms that are doing background things (big makes,
etc.) and set the history buffer real long (so I can scroll
back through the output if there are errors, etc.)

<shrug>  It's not "ideal" but I find it pretty productive.

> Also, for those out there who think KDE and Gnome have nothing to do
> with font rendering: you are dead wrong.
> 
> *MOST* fonts can be handled by X now, but quite a few cannot. Apps still
> need to do some of the work themselves.
> 
> In particular, xterm fails to render some monospaced fonts properly, because

Hmmm... really?  I've not seen that -- except if the called for
font is not available and it has to substitute some other font.
That was the problem I saw when trying to run CDE on the NCD's
(before I moved the Sun fonts onto the font server).  In
those cases, it can look REALLY ugly.  :-(

> it lacks the font support found in KDE and Gnome.  xterm recently got 
> better font support, and since it is actively developed, the problem
> should be fixed.
> 
> Either that, or the remaining font code will be completely moved to X.
> 
> I suppose at that point libraries like Pango will be more for font management
> than rendering.
> 
>> Get up and take a break!  :>  It's GOOD for you to do, anyway
>> (let your eyes focus on something besides a close-in screen).
> 
> That's pretty obvious, and I've been operating like that for 20 years
> now.
> 
> It doesn't matter after you've been working for a certain number of hours.

I work out of my home so there are ALWAYS enough OTHER things
to pull me away from the screen for an hour at a time.  :>
The biggest problem I face is that they aren't OFTEN enough.

>>> My original issue was just that when not running the desktop, I lost
>>> good rendering of fonts and widgets.
>> But that would be the desktop code?
> 
> If an application cannot or will not load support libraries when running
> under a plain window manager, then things go bad sometimes.
> 
> In particular, a lot of GTK/Gnome apps must have Pango loaded to do
> fonts properly.

OK, so it's the applications that have been designed EXPECTING
to run under a certain environment.  It would be like running
a windows product that expects T1 fonts while only TTF are
available...

> Given time, this should be resolved.  X has improved a great deal in
> recent years.
> 
>> Yup.  In my case, since I don't work in a desktop, those apps just
>> look silly "on their own".
> 
> I suppose the positive side is that they run faster.
> 
> I used to never use desktop applications, but there are several that
> are excellent now.
> 
> I just catalogued my book collection using Tellico, 172 books, in about
> 1 hour.
> 
> Doing that with vi and bibtex would have taken weeks.

I'm doing similar, currently.  But, using a home-grown web-based
interface to a PostgreSQL database (I want it accessible from
other machines as well as the framework in place for cataloging
other things -- CD's, software, equipment, etc.)

> Of course, I hate how people write GUI apps: all the code integrated.
> 
> If Tellico (and other apps) were written as wrappers on non-GUI
> libraries and programs, then we could do the same work on the command
> line if we wanted to.

That's how I have built my applications (of course, you can't
view things like book covers from the command line... but, you
can search for titles, do data entry, etc. without NEEDING
the browser interface)

> I've always like software that runs great with or without its GUI.
> 
>>> I'd like to see uniform application support in X, and see it without
>>> having to have a million different competing widget libraries
>>> loaded.
>> Fresco would have been an interesting rehash.
> 
> You know, I never minded Motif myself. If the Open Group, or whoever it was,
> had not been so bloody stupid, it would have been used everywhere, and let's
> face it: Motif could have been fixed, 2.x didn't have to be the mess it was,
> and in time it could have been just as featureful as any current system.
> 
> But, now we have:
> 
> 	Motif, slowly dying.

Had they opened up the licensing, they would have had a chance
years ago.  Now, people have developed (rightly so?) the attitude
that "we can do that on our own...".  So, too late for Motif.

> 	KDE, rapidly improving, but rather C++ focused.  I find this one
> 	usable without getting in my way.
> 
> 	Gnome, tying itself in a knot to copy Windows and .NET, and
> 	the hell with production quality and resource usage.

Ah, but not to worry... I am sure Windows will "win" that race!
(I am no longer amazed at how bloated these folks can make things
and STILL leave plenty of room for bugs!!!)



More information about the rescue mailing list