--- In iolanguage@yahoogroups.com, "Jon Kleiser" <jon.kleiser@u...> wrote:
...
> I once believed that Io's OpenGL/Font implementation was unable to display
characters
> with ASCII codes above 127 (incl. the Norwegian æ-ø-å). Now I've found that
this is only
> partly true. To demonstrate this, I've made a little script that's available
here:
> <http://folk.uio.no/jkleiser/io/fontTest.io>
> (It works on Mac, not too well on Windows. I haven't tried it on other
systems.)
>
> The first thing I noticed, was that the capability to display the characters I
was interested
> in, depended on the font's pixelSize. If this size was below 34, I could not
see my
> special characters (at the right). As I increased the size from 34 to 42 the
special
> characters started to appear, first in the Vera fonts, then in the Free fonts.
>
> If you run my fontTest.io, you'll see that I've also tried to scale down the
sample text,
> shown in blue at the bottom. Here I noticed that, if the special character is
showing,
> then the downscaling will break. Try it!
...
> As you may see in my code, I've tried to use the Font error method, but when I
use that I
> get a Bus error, so I've just commented it out.
>
> Then the Font drawString method. ... it allowed me to do drawString(string,
number),
> but I have not figured out yet what the effect of that is supposed to be.

I took a look at IoFont.c and found the meaning of the two optional parameters
for Font
drawString: startIndex and endIndex. I have modified my fontTest.io to use the
startIndex,
but that feature don't always work. When the font's pixelSize is big enough for
the special
characters to appear, then those optional parameters seem to be ignored. In my
fontTest.io you can see this when a ">" appears at the beginning of the line.
I've tested this with Mac OS X, both 10.3.7 and 10.4(pre).

/Jon

On Dec 22, 2004, at 11:49 PM, Jon Kleiser wrote:
> --- In iolanguage@yahoogroups.com, "Doc O'Leary" <doc_oleary@y...>
> wrote:
>> More to the point, I have been updating all the NeHe
>> tutorials and submitted working versions of 9 and 10 to Steve over 2
>> months ago.  And
>> my 10 even matched the tutorial more properly by parsing the original
>> NeHe world file.
>
> If you still have your updated NeHe lessons (especially #10) around,
> could you please
> (a) make them available from your home page, or
> (b) send them to me (jon.kleiser at usit.uio.no), and I'll put them up
> at my Io page. (Then
> Steve can include them in his distribution whenever he feels like it.)

Doc,

I'm sorry if I forgot to include them. Can you please resend them?

-- Steve

On Dec 24, 2004, at 3:52 AM, Jon Kleiser wrote:
> The first thing I noticed, was that the capability to display the
> characters I was interested
> in, depended on the font's pixelSize. If this size was below 34, I
> could not see my special
> characters (at the right). As I increased the size from 34 to 42 the
> special characters
> started to appear, first in the Vera fonts, then in the Free fonts.

The problem is that you're doing a glScaled() on some of the fonts.
That works ok if they are being represented as textures, but it breaks
if they are rendered with bitmaps. The Font primitive only uses
textures for small fonts since texture memory is limited.

-- Steve

I've been on a language trip lately, and so gave AOP a shot in Io.  It's
based on the Proxy pattern -  messages are sent to the Aspect object,
which decide what do do - generate a log entry, check for security, or
in the demo's case, check that a balance has sufficient funds before
withdrawing.  It only supports 1 aspect, so it's not very usable.  It's
more of a tinkering.  Anybody have any ideas to expand it?  I'd really
like the object itself to forward to aspects, but all I could think of
is overriding getSlot and setSlot.  The problem with that is it would be
hard to later get into the object normally.

The demo here should print:

Withdrew 50
Withdrew 50
Insufficient Funds

------------------------------------------------------------

AOPObject := Object clone do (
  object := Nil
  aspect := Nil

  setObject := method ( object,
    self object = object
    return self
  )

  addAspect := method ( aspect,
    self aspect = aspect
    aspect object := object
    return self
  )

  forward := method (
    thisMessage doInContext( aspect )
  )
)

Aspect := Object clone do (
  forward := method (
    thisMessage doInContext( object )
  )
)

Account := Object clone do (
  balance := 0
  deposit := method( amount,
    balance = balance + amount
  )
  withdraw := method( amount,
    balance = balance - amount;
    write( "Withdrew ", amount, "\n" )
  )
)

AccountBalance := Aspect clone do (
  withdraw := method( amount,
    if ( object balance <= 0 ) then ( write( "Insufficient Funds\n" );
return )
    thisMessage doInContext( object )
  )
)

account := AOPObject clone setObject( Account clone ) addAspect(
AccountBalance )

account deposit( 100 )
account withdraw( 50 )
account withdraw( 50 )
account withdraw( 50 )


Regards,
Mike

On Sun, 02 Jan 2005 12:48:48 -0800, Mike Austin <mike@...> wrote:
> I've been on a language trip lately, and so gave AOP a shot in Io.  It's

You're no doubt familiar with the fact that many patterns are
language-specific,right? The Visitor pattern, for example, is entirely
unneeded in CLOS (Lisp's object system), thanks to multiple dispatch.

In the same way, aspect-oriented programming is unneeded in Io, thanks
to Io's thorough use of dispatching, prototyping, and run-time
modification. Do you want to add a method to certain types of classes?
Okay, refactor the classes so that the "certain types" are a single
prototype, delegate to that prototype, and then modify the prototype.

And so on.

It would be wise, of course, to establish common conventions for use
of the dispatching that would make different people's AOP compatible
with one another. One possible convention would be a standard way of
adding an additional object to any object's dispatch chain. Right now
there's quite a few different ways to do that.

> Mike

-Billy

--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@d...> wrote:
>
> On Dec 24, 2004, at 3:52 AM, Jon Kleiser wrote:
> > The first thing I noticed, was that the capability to display the
> > characters I was interested
> > in, depended on the font's pixelSize. If this size was below 34, I
> > could not see my special
> > characters (at the right). As I increased the size from 34 to 42 the
> > special characters
> > started to appear, first in the Vera fonts, then in the Free fonts.
>
> The problem is that you're doing a glScaled() on some of the fonts.
...
> -- Steve

Is it really? In the new <http://folk.uio.no/jkleiser/io/fontTest2.io>, I've now
commented
out the glScaled(0.5, 0.5, 1) and the drawing of the blue (downscaled) text, and
to be sure,
I also commented out the glScaled(3.4, 3.4, 0) and the lines related to the
glutStrokeString, but the oddities remain: When the pixelSize is big enough for
the high
ASCII characters to appear, the optional parameters of Font drawString are
ignored. (The
Font error method also still gives me a Bus error.) Am I missing something?

/Jon

Since Yahoo groups is bouncing my other address, let's
try this...

William Tanksley, Jr wrote:

> On Sun, 02 Jan 2005 12:48:48 -0800, Mike Austin
<mike@...> wrote:
>
>> I've been on a language trip lately, and so gave
AOP a shot in Io.  It's
>
>
> You're no doubt familiar with the fact that many
patterns are
> language-specific,right? The Visitor pattern, for
example, is entirely
> unneeded in CLOS (Lisp's object system), thanks to
multiple dispatch.

You mean *not* language-specific, right?  Yes, and
that's why I like languages that can express almost
any kind of pattern by using the runtime.  Multiple
dispatch could probably be added to Io, although it's
probably not the right direction.

> In the same way, aspect-oriented programming is
unneeded in Io, thanks
> to Io's thorough use of dispatching, prototyping,
and run-time
> modification. Do you want to add a method to certain
types of classes?
> Okay, refactor the classes so that the "certain
types" are a single
> prototype, delegate to that prototype, and then
modify the prototype.


Since Aspect Oriented is a style of programming, I'm
not really introducing a new concept, just forming a
pattern.  I don't really like how AOP is implemented
in static languages - especially introducing new
terminology such as pointcuts, joinpoints and advice.
As I see it, it's really not as complicated as they
make it.

> And so on.
>
> It would be wise, of course, to establish common
conventions for use
> of the dispatching that would make different
people's AOP compatible
> with one another. One possible convention would be a
standard way of
> adding an additional object to any object's dispatch
chain. Right now
> there's quite a few different ways to do that.


Exactly.  I have modified my previous test,
introducing the method "aspectClone" which clones an
object and creates the proxy internally for you.  To
give people a more visual sense of what's going on:

Normally, slots are looked up by starting at the
object, then looking in it's proto, then it's proto's
proto, etc.:

object -> proto -> proto

My pattern simply inserts protos on the left side of
the object, so slots are looked up in the first
aspect, the next, and finally the actual object:

aspect -> aspect -> object

As you can see, this is why a proxy is needed.  You
can't use a reference to the first aspect, because
another may be inserted or it itself may be removed.
So the final chain may look something like:

proxy -> aspect -> object -> proto

Aspects have access to the objects slots, just like
protos.  But because they are higher in the chain,
they can take action or make decisions before the
object's methods are actually called.

----------

Object aspectClone := method (
  aspect := AOPObject clone
  aspect object := self clone
  return aspect
)

Aspect := Object clone do (
  forward := method (
    write( "Aspect forward()\n" )
    return thisMessage doInContext( object )
  )
)

AOPObject := Object clone do (
  object := Nil
  aspect := Aspect clone

  addAspect := method ( aspect,
    self aspect = aspect
    aspect object := object
  )

  forward := method (
    write( "AOPObject forward()\n" )
    return thisMessage doInContext( aspect )
  )
)

LogMessages := Aspect clone do (
  forward := method (
    write( "Executed '", thisMessage name, "'\n" )
    return thisMessage doInContext( object )
  )
)

test := List aspectClone addAspect( LogMessages )
n := test count

----------

Regards,
Mike



__________________________________
Do you Yahoo!?
Jazz up your holiday email with celebrity designs. Learn more.
http://celebrity.mail.yahoo.com

I'm trying to figure out the meaning of the second parameter of the Font
stringIndexAtWidth method. In IoFont.c it's called "startIndex" (and the third
parameter is
called "width".)
If I use the Free/Mono/Normal.ttf font with a pixelSize of 12, and keep the
string and width parameters constant at "AAAAAAAAAAAAAAA" (15 A's) and 70
respectively, I can let the startIndex run from 0 through 15. The values
returned by
stringIndexAtWidth will then be 10 for startIndex values up to (and incl.) 5.
From there,
the returned value will decrease by 1 for each increase in the startIndex. Is
this the way it's
supposed to be?

/Jon

Hello everyone

I've got the most recent IoVM (IoVM-2004-12-16) and cygwin package
(updated today) on my win32 machine.

When I run the examples in the Concurency directory, most of them
crash.

for example:

$ io Continuation.io
1 - in main, sent async message, yielding
2 - in foo, pausing
3 - in main, after yield
4 - in foo, after pause
5 - in main, after resume
Segmentation fault (core dumped)

The stackdump is:

Exception: STATUS_ACCESS_VIOLATION at eip=11000000
eax=11000000 ebx=0A0A10C0 ecx=61113060 edx=00000000 esi=0A051110
edi=0A0A18C8
ebp=0022EF30 esp=0022EF20 program=......\io.exe, pid 2392,
  thread main
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EF30  11000000  (0A0A10C0, 000000BC, 0A05AAD8, 0A050CD0)
0022EF4C  0040C841  (0A051110, 0A0501E8, 0A051130, 0A051110)
0022EF7C  0040EE1C  (0A0501E8, 0A0501E8, 0A0511B0, 0A096968)
0022EF98  00401B9F  (0A0501E8, 0A096968, 0A096968, 0A0501E8)
0022EFC8  0040109D  (00000002, 61792C9C, 0A0500A8, 0022F020)
0022F008  61006145  (0022F020, 0022F31C, 77F64EAC, 0022F340)
0022FF88  61006350  (00000000, 00000000, 00000000, 00000000)
End of stack trace

Future.io and _tests/performance/threads.io also crash.

On Jan 4, 2005, at 6:53 AM, Jon Kleiser wrote:
> I'm trying to figure out the meaning of the second parameter of the
> Font
> stringIndexAtWidth method. In IoFont.c it's called "startIndex" (and
> the third parameter is
> called "width".)
> If I use the Free/Mono/Normal.ttf font with a pixelSize of 12, and
> keep the
> string and width parameters constant at "AAAAAAAAAAAAAAA" (15 A's) and
> 70
> respectively, I can let the startIndex run from 0 through 15. The
> values returned by
> stringIndexAtWidth will then be 10 for startIndex values up to (and
> incl.) 5. From there,
> the returned value will decrease by 1 for each increase in the
> startIndex. Is this the way it's
> supposed to be?

Yes. Why do you think it wouldn't be?

-- Steve

On Jan 4, 2005, at 6:44 AM, June Kim wrote:
> I've got the most recent IoVM (IoVM-2004-12-16) and cygwin package
> (updated today) on my win32 machine.
>
> When I run the examples in the Concurency directory, most of them
> crash.

They work fine for me on OSX.
Can someone else confirm this bug on Windows?

-- Steve

Hi Jon,

Let's say you're typesetting a text file.
You need to break the text onto lines of a specific width.
If the text file is textStr and the line width is w, then

numChars = font stringIndexAtWidth (textStr, startIndex, w)

gives you a line of text that fits within w,
from startIndex to (startindex+numChars-1).
For the next line, startIndex += numChars, and so forth.

Of course, that's a pretty stupid line break algorithm,
since it's paying no attention to word breaks, but you get the idea.

In your example, "A" has a width of 7, so in a box of width 70, you get 10 "A"s.
Your string begins with 15 "A"s, so you keep getting 10 back until
the string passed in contains 9 "A"s, 8 "A"s, etc.
Passing in a 15 for startIndex yields 0 since that's past the end of the string.

-- Rick

--- In iolanguage@yahoogroups.com, "rickevans123" <yahoo@b...> wrote:
>
> Hi Jon,
>
> Let's say you're typesetting a text file.
> You need to break the text onto lines of a specific width.
> If the text file is textStr and the line width is w, then
>
> numChars = font stringIndexAtWidth (textStr, startIndex, w)
>
> gives you a line of text that fits within w,
> from startIndex to (startindex+numChars-1).
> For the next line, startIndex += numChars, and so forth.
>
> Of course, that's a pretty stupid line break algorithm,
> since it's paying no attention to word breaks, but you get the idea.
> ...
> -- Rick

Thank you for the fine explanation! I've just had a look at
GLFont_stringIndexAtWidth in
GLFont.c, and I'm getting the picture. Here's what I think could be a suitable
description of
stringIndexAtWidth in the Font docs:

stringIndexAtWidth(aString, startIndex, widthNumber)
Returns the number of characters, starting with startIndex, that fits within a
width of
widthNumber pixels (also measured from the startIndex). The last counted
character is
only required to fit halfway.

The "halfway" requirement for the last character of course has to do with the
use in a text
field where the user may click close to the middle of a character, and the
cursor has to be
put at the right hand side of the character if the click was slightly over to
the right.

/Jon

Hello,

Regarding the font rendering issues Jon recently mentioned, the problem is that
the
two rendering methods (texture/pixmap) don't match up:

(1) Smaller sizes are textured (i.e., cached), but only characters 32-127 are
textured.
The full font is considered textured though, so at render time, the high
characters
find the cupboard bare, and simply don't appear.
We should either texture the entire font, or if that's too big a memory hit,
always pixmap-render uncached characters, especially 128-255.

(2) The point sizes deemed too large to texture are drawn via
GLFont.c:GLFont_drawPixmapString_(). This works fine, though
startIndex and endIndex are _not_ honored (they _are_ honored in
GLFont_drawTextureString_() ), thus the ">" bug Jon reported.

Thankfully these seem like small bugs. I've been using some of my own OpenType
fonts, e.g. Adobe Caslon, and they render beautifully and completely at large
point sizes.
Actually my TrueType fonts, including Vera and Free don't render, and I'm not
sure why.
OpenType fonts work fine. This hasn't bothered me since they're working for
other people,
but does anyone have an idea why this is the case?

-- Rick

--- In iolanguage@yahoogroups.com, "Jon Kleiser" <jon.kleiser@u...>
wrote:
> stringIndexAtWidth(aString, startIndex, widthNumber)
> Returns the number of characters, starting with startIndex, that
fits within a width of
> widthNumber pixels (also measured from the startIndex). The last
counted character is
> only required to fit halfway.

Yikes! That's true, the last character is counted if it fits more
than halfway. That can't be right! There's no such thing as 55% of an
"A".
Either the "A" fits on the line, or it doesn't.
10 "A"s of width 7 fit neatly on a 70-width line, and if the line is
79-wide, there can still be only 10 "A"s.

-- Rick

On Jan 5, 2005, at 5:40 AM, rickevans123 wrote:
> Yikes! That's true, the last character is counted if it fits more
> than halfway. That can't be right! There's no such thing as 55% of an
> "A".
> Either the "A" fits on the line, or it doesn't.

That's true but the purpose of this method is to determine where a
mouse click maps to in some on-screen text. It's not for calculating
line breaks. Another method for calculating line breaks would be useful
though.

-- Steve

On Wednesday, January 5, 2005, at 01:38  PM, Steve Dekorte wrote:
> Another method for calculating line breaks would be useful though.

I can just taste an OpenGL word processor.  Then we'd just need an
OpenGL to PostScript converter for printing.

Originally, I thought this in jest, but now I'm wondering if there
would be some merit to the idea.

--
Daniel
http://www.storytotell.org -- Tell It!

On Jan 5, 2005, at 12:48 PM, Daniel Lyons wrote:
> I can just taste an OpenGL word processor.

A good Text object for Ion would be wonderful!

> Then we'd just need an OpenGL to PostScript converter for printing.

Hmm, now that computers and printers have plenty of memory, can we just
dump out pages as pixel maps and push them to the printer?

-- Steve

On Wednesday, January 5, 2005, at 02:11  PM, Steve Dekorte wrote:

> > Then we'd just need an OpenGL to PostScript converter for printing.
>
> Hmm, now that computers and printers have plenty of memory, can we just
> dump out pages as pixel maps and push them to the printer?

Well, yes and no.  Printers don't usually have endless memory (8-16 MB
is still considered "a lot"), and though PostScript is wordy, it's not
that wordy (unless your PostScript is just a wrapper for some image).
Many printers do interesting tricks with PostScript to make it look
sharper as it comes out.  Typographers would probably be deeply
offended at the prospect, but I'm not convinced it would be very
noticeable to the average human, coming out of an average printer.

I'm also not convinced that it would be impossibly difficult to convert
OpenGL--or a reasonable subset of it--to PostScript.  But like I said,
I really don't know much of anything about it.

--
Daniel
http://www.storytotell.org -- Tell It!

On Jan 5, 2005, at 1:17 PM, Daniel Lyons wrote:
> Well, yes and no.  Printers don't usually have endless memory (8-16 MB
> is still considered "a lot"), and though PostScript is wordy, it's not
> that wordy (unless your PostScript is just a wrapper for some image).

It seems those printers must be able to handle it, as I've seen them
print out large photos. And converting those images to Postscript will
only make them larger.

> Many printers do interesting tricks with PostScript to make it look
> sharper as it comes out.  Typographers would probably be deeply
> offended at the prospect, but I'm not convinced it would be very
> noticeable to the average human, coming out of an average printer.
>
> I'm also not convinced that it would be impossibly difficult to convert
> OpenGL--or a reasonable subset of it--to PostScript.  But like I said,
> I really don't know much of anything about it.

I think a subset is doable, but I don't find that solution attractive
as it's so limited. Maybe we could convert the image of the page to
Postscript for printers that require postscript files? I bet there's
some open source RGB to PS conversion code out there...

-- Steve

That's odd; we're using it for linebreaks in Europa and it's working
beautifully.

Well, we're also using word-breaks, as it happens, but we're using that
on top of the other.

On Jan 05, 2005, at 3:38 PM, Steve Dekorte wrote:

>
>  On Jan 5, 2005, at 5:40 AM, rickevans123 wrote:
>  > Yikes! That's true, the last character is counted if it fits more
>  > than halfway. That can't be right! There's no such thing as 55% of
> an
>  > "A".
>  > Either the "A" fits on the line, or it doesn't.
>
>  That's true but the purpose of this method is to determine where a
>  mouse click maps to in some on-screen text. It's not for calculating
>  line breaks. Another method for calculating line breaks would be
> useful
>  though.
>
>  -- Steve
>
>
>
> Yahoo! Groups Links
>
>  •  To visit your group on the web, go to:
> http://groups.yahoo.com/group/iolanguage/
>  
>  • 	 To unsubscribe from this group, send an email to:
> iolanguage-unsubscribe@yahoogroups.com
>  
>  • 	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
_____________________
Rob Rix, composer &c.

I work in a print shop. Please no! There are a lot of advantages to
having proper fonts sent through, not the least of which is (in our
environment) RIP/spool time. Our network is fast, but our RIP is not,
and it's only got a limited amount of room onboard, and it's an
advantage to us to have as many recent jobs in the RIP at once as is
possible-- so we can print extras straight off the RIP without having
to re-spool, for instance.

Also, it just feels wrong (:

On Jan 05, 2005, at 4:11 PM, Steve Dekorte wrote:

>
>  > Then we'd just need an OpenGL to PostScript converter for printing.
>
>  Hmm, now that computers and printers have plenty of memory, can we
> just
>  dump out pages as pixel maps and push them to the printer?
>
>
_____________________
Rob Rix, designer &c.

--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@d...> wrote:
> It seems those printers must be able to handle it, as I've seen them
> print out large photos. And converting those images to Postscript will
> only make them larger.

Yes, PostScript does that without blinking. The main difference is
resolution independence. That difference is sharpest when you print a PDF
of, say, a book chapter that is either generated PostScript or else scanned
pages
that become big honking TIFFs or JPEGs simply wrapped in a little PostScript.
The former is rasterized on-the-fly by the PostScript interpreter in the
printer,
while the latter must be fully loaded into printer memory before
the interpreter can even think about it. Memory-intensive and way slow.

The scanned pages also suck as they don't scale. That's OK for images, but
text is delicate. People will howl if you bitmap their text and take PostScript
out of the loop.

-- Rick

On Jan 5, 2005, at 4:45 PM, rickevans123 wrote:
> The scanned pages also suck as they don't scale. That's OK for images,
> but
> text is delicate. People will howl if you bitmap their text and take
> PostScript
> out of the loop.

I think there may be some confusion here about what is being discussed.
No one is suggesting using non-scalable formats to exchange word
processing files.

The question is how to print a page. And on a printer (just like a
screen), all documents ends up as a pixelmap eventually, as that is
what is used to drive the laser, or inkjet, etc.

-- Steve

http://www.iolanguage.com/Downloads/

Release 2005 01 05 - ffmpeg, fixes
================================
- moved Movie from using mpeg2dec lib to use the libavformat &
libavcodec
    this fixes some bugs and adds support for more fomarts
- TIFF color fix (by Rick Evans)
- fix for OpenGL lessons (by Jon Kleiser and Doc O'Leary)
- updated Io mode for Emacs (by xihr)

Notes
=====
The Movie primitive now supports a bunch of new formats and codecs,
including VOB, mpeg4, and others. I'm working on adding audio support
as well.

--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@d...> wrote:
> I think there may be some confusion here about what is being discussed.
> No one is suggesting using non-scalable formats to exchange word
> processing files.

  No confusion. Sorry if I wasn't clear.

> The question is how to print a page. And on a printer (just like a
> screen), all documents ends up as a pixelmap eventually, as that is
> what is used to drive the laser, or inkjet, etc.

But it depends upon when the page is rasterized, and at what resolution.
If you take a snapshot of the onscreen page at 90 dpi and fire it off to
the printer to print at 600 dpi, you're bitmap scaling. If you send off a
PostScript description of the page instead, the interpreter will do its
thing and maintain the crisp outlines at whatever dpi you're printing.

But all that aside, what you asked for is doable.
Also what Daniel mentioned is doable: I've seen
available OpenGL-to-PS code, though it's LGPL.

Actually I think writing a Text object would be more fun.

Wow, we're far afield from this thread's title.

-- Rick

On Jan 5, 2005, at 7:22 PM, rickevans123 wrote:
>  But it depends upon when the page is rasterized, and at what
> resolution.
>  If you take a snapshot of the onscreen page at 90 dpi and fire it off
> to
>  the printer to print at 600 dpi, you're bitmap scaling. If you send
> off a
>  PostScript description of the page instead, the interpreter will do
> its
>  thing and maintain the crisp outlines at whatever dpi you're printing.

If it's all the same, I'd rather convert to PS and then submit, for the
sake of the network and the poor printer.  :)  Especially if we have to
anyway.

>  But all that aside, what you asked for is doable.
>  Also what Daniel mentioned is doable: I've seen
>  available OpenGL-to-PS code, though it's LGPL.

Isn't that co-optable?

>  Actually I think writing a Text object would be more fun.

So... are we actually interested in writing an OpenGL word processor,
or do you mean something else by that?  I mean, naturally, we'd rather
have an object that maintains the state, saves to disk, and produces
PostScript natively (or whatever).

--
Daniel
http://www.storytotell.org -- Tell It!

On Jan 5, 2005, at 6:22 PM, rickevans123 wrote:
> --- In iolanguage@yahoogroups.com, Steve Dekorte <steve@d...> wrote:
>> The question is how to print a page. And on a printer (just like a
>> screen), all documents ends up as a pixelmap eventually, as that is
>> what is used to drive the laser, or inkjet, etc.
>
> But it depends upon when the page is rasterized, and at what
> resolution.
> If you take a snapshot of the onscreen page at 90 dpi and fire it off
> to
> the printer to print at 600 dpi, you're bitmap scaling.

Yes, but I don't understand why you would do that. Is there something
preventing you from sending a 600dpi version to the 600dpi printer?

> But all that aside, what you asked for is doable.
> Also what Daniel mentioned is doable: I've seen
> available OpenGL-to-PS code, though it's LGPL.
>
> Actually I think writing a Text object would be more fun.

And more useful in the end, as hardcopy will hopeful die within our
lifetimes. :-)

-- Steve

On Jan 5, 2005, at 6:22 PM, rickevans123 wrote:
> --- In iolanguage@yahoogroups.com, Steve Dekorte <steve@d...> wrote:
>> The question is how to print a page. And on a printer (just like a
>> screen), all documents ends up as a pixelmap eventually, as that is
>> what is used to drive the laser, or inkjet, etc.
>
> But it depends upon when the page is rasterized, and at what
> resolution.
> If you take a snapshot of the onscreen page at 90 dpi and fire it off
> to
> the printer to print at 600 dpi, you're bitmap scaling.

Right, but is there something preventing one from sending a 600dpi
version to the 600dpi printer?

> But all that aside, what you asked for is doable.
> Also what Daniel mentioned is doable: I've seen
> available OpenGL-to-PS code, though it's LGPL.
>
> Actually I think writing a Text object would be more fun.

And more useful in the end, as hardcopy will hopeful die within our
lifetimes. :-)

-- Steve

On Wed, 5 Jan 2005 14:00:37 -0800, Steve Dekorte <steve@...> wrote:
> It seems those printers must be able to handle it, as I've seen them
> print out large photos. And converting those images to Postscript will
> only make them larger.

Postscript printers have two-way communications with the printing
computer (even if it's a simple "busy" indicator on the parallel
port), so the memory consumption used for interpreting the Postscript
program is limited (remember: Postscript was invented when the 512K
Macintosh was consider the latest thing).  Postscript is stack-based
for a reason: it exhibits the property of concatenativity, and as
such, you can break the program at (almost) any point and have two
valid sub-programs (you can't do this with traditional applicative
languages).  Hence, Postscript is ideal for *streaming* to the
printer, which can interpret it in managable chunks.

Usually.

Font data has to be loaded in its entirety, but otherwise, my comments
on Postscript are valid as far as I know.

> Postscript for printers that require postscript files? I bet there's
> some open source RGB to PS conversion code out there...

How long are you willing to wait for pages to be printed?  Spitting
out bitmaps, especially bitmaps at the printer's native resolution,
will take immense amounts of time.  Doable, yes.  I've done it before
(not any programming I've done, but still).  But boy it sure takes
forever.  :(

--
Samuel A. Falvo II