World: r3wp

But you're right, that if you really want that, then you need to 
get info from each letter in the font.

yes! now you get it

:) In REBOL/View, there is things like offsets to position text within 
field and so. Couldn't you go with something like that? Just subtract 
a little from each vertical position to get the text a little down, 
if you want?

then I have to do that for each single individual case. with the 
deadline I have to produce this table, that may be my option for 
now, but that is definitely not optimal.

If you have different fontsizes in your tables, you could do something 
like:
y-pos: y-pos - (fontsize / 10)

Then adjust the 10 factor, until you're satisfied. And that should 
then work for all fontsizes.

well, possibly. I'll see if that works for now.

Sorry, that I find it hard to understand, what you mean from time 
to time, my fault. I get you now. I would put things like margins, 
linespace, vertical position within tables, etc. in a dialect above 
the postscript dialect level. Doing it that way, the same postscript 
dialect can be used for all sorts of layout engines, because it has 
little restriction.

for the syntax and input yes, but if you need accuracy, you need 
to get the information via postscript.

ok

because we are already doing it correctly using stringwidth, namely 
by calculating the text size accurately inside postscript. the same 
should count for the vertical size. it's strange that information 
is so hard to get.

Don't you think, it already is centered, if you take underline into 
consideration? It seems weird to me, that Adobe would position text 
being off some amount, either up or down.

it is not centered, because the baseline is not at the center of 
the text. if only it were :-)

and the position calculation is around the baseline.

That is the reason, that they put the baseline as they did?

the baseline is a typographical tool. it is the place where your 
letters are "resting" against, just like when you were learning to 
write in school, you had a guide line to write characters on. but 
the baseline itself is completely useless for vertical centering 
of text.

adobe didn't invent the baseline

but I do wish that each char in a font had a center point that indicates 
the absolute center of a character both horizontally and vertically. 
horizontally, that would be individual for each char, but vertically 
it has to be identical for all chars, like the baseline is.

I can see, that text in tables in html is centered more like you 
want it, at least in Safari. Actually the text is much lower in Safari, 
so there is more space above the text than below, if you use words 
with 'g'. I can't judge, if they do a simple calculation or use the 
font box.

it depends on the chars you use. if you use a word like "judge", 
the word might appear offset downward, because there are no really 
tall letters in that word. if you use a word like "Greg", the word 
might appear more centered. If you say "GGG", the word might appear 
offset upward, because "G" is a tall character in Helvetica or Times. 
But overall, if you write a long sentence like that, the words should 
appear centered.

And when I say the letter is tall in Helvetica or Times, that means 
it may not be so in other fonts. I don't believe a font like Verdana 
does this. This is why when getting the absolute center for a font, 
you must calculate it using all glyphs in the font.

I gave in, and have begun using ghostscript for printing postscript. 
There are many printer specific bugs that require a windows printer 
driver to make postscript printing work properly, so I now use the 
mswinpr2 driver. However it eats about 40 MB RAM printing one page. 
Anyone got ideas on how to reduce that?

what do you mean by printer specific bugs?

I had problems with feeding postscript files generated by postscript.r 
directly to an HP Laserjet 1200. It would stop printing after the 
first job. Feeding it through Ghostscript or the adobe postscript 
printer driver solved the problem, but now the printer is replaced 
with a different one with different issues.

I read about the HP Laserjet 1200 and it has such a bug in its postscript 
implementation that is easiest worked around in the driver.

I've also seen a Laserjet 4500 lock completely up, when you feed 
it a specific postscript or PDF file.

and you're sure that your postscript code is correct??

I have worked for many weeks on the problem and it's unsolvable, 
so I went to Ghostscript instead, but I'm unhappy with its speed.

what happens when the code you send is rendered by gsview?

or is interpreted interactively by ghostscript?

I don't use GSView, I use the printer with Ghostscript as passthrough.

so, you send postscript to ghostscript when then generates postscript 
again to send to the HP printers?

No, ghostscript generates a bitmap for printing on any printer, which 
is what I have to use now. I used the adobe driver for the HP 1200.

so, you're also using gsprint?

I call gswin32c.exe and feed it parameters to use the win32pr driver, 
which sends a bitmap to the printer given as a parameter in the same 
call.

will have a look at gsprint...

the point of using gsview is as a debugging tool

but I guess gswin32 should complain if there is an error in the ps 
code

I don't use GSView at all.

I don't think it's the postscript itself that's buggy, but the transmission 
of the code to the printer. Perhaps they are screwing around with 
port settings inside the driver which we don't know about. So it 
may be a lower level problem.

Is it a shared printer?

nope

so, you just writing to port 9100 ?

doesn't that only work for ethernet printers?

I got some notes somewhere that async printing to a postscript printer 
caused me problems.

what sort of printer is it??

It uses parallel/usb

and which were you using?

HP Laserjet 1200

parallel or usb?