[9fans] p9p troff/ps problem, comparison with heirloom

[9fans] p9p troff/ps problem, comparison with heirloom

[erik quanstrom]

this does work on my system.  here's the diff:

- erik

-----
/n/sources/plan9//sys/src/cmd/eqn/text.c:1,6 - text.c:1,7
  #include "e.h"
  #include "y.tab.h"
  #include <ctype.h>
+ #include <utf.h>
  
  #define	CSSIZE	1000
  char	cs[CSSIZE+20];	/* text string converted into this */
/n/sources/plan9//sys/src/cmd/eqn/text.c:42,48 - text.c:43,49
  	wchar_t r;
  	int w;
  
- 	w = mbtowc(&r, psp, 3);
+ 	w = mbtowc(&r, psp, UTFmax);
  	if(w == 0){
  		psp++;
  		return 0;
/n/sources/plan9//sys/src/cmd/eqn/text.c:49,55 - text.c:50,56
  	}
  	if(w < 0){
  		psp += 1;
- 		return 0x80;	/* Plan 9-ism */
+ 		return Runeerror;	/* Plan 9-ism */
  	}
  	psp += w;
  	return r;
/n/sources/plan9//sys/src/cmd/eqn/text.c:112,128 - text.c:113,125
  	printf(".ds %d \"%s\n", yyval, p);
  }
  
- int isalpharune(int c)
- {
- 	return ('a'<=c && c<='z') || ('A'<=c && c<='Z');
- }
- 
  int isdigitrune(int c)
  {
  	return ('0'<=c && c<='9');
  }
  
- trans(int c, char *p1)
+ int
+ trans(int c, char *)
  {
  	int f;
  
/n/sources/plan9//sys/src/cmd/eqn/tuning.c:146,151 - tuning.c:146,155
  		target = &Subbase;
  	else if (eq(s, "Supshift"))
  		target = &Supshift;
+ 	else{
+ 		ERROR "unknown ftune" FATAL;
+ 		return;
+ 	}
  	if (t[0] == '+' || t[0] == '-')
  		*target += f;
  	else

[9fans] p9p troff/ps problem, comparison with heirloom

[Rudolf Sykora]

Dear Erik,

thank you for looking at the problem. Nonetheless, I am bit puzzled.

The problems I have described exist in plan9port and heirloom
software. I haven't yet tried to what extent it also applies to plan9
proper. And it seems you are suggesting some changes to the latter
software.

Also, at least partly, I guess, some of my problems on linux are
caused by non-existing lucida sans fonts (and all the mess around
fonts around troff/gs and unicode coverage).

So what problem should your change remove? (I am sorry it's not clear
to me from your code.)

Thank you
Ruda

On 11 November 2011 16:56, erik quanstrom <quanstro at quanstro.net> wrote:
> this does work on my system. ?here's the diff:
>
> - erik
>
> -----
> /n/sources/plan9//sys/src/cmd/eqn/text.c:1,6 - text.c:1,7
> ?#include "e.h"
> ?#include "y.tab.h"
> ?#include <ctype.h>
> + #include <utf.h>
>
> ?#define ? ? ? CSSIZE ?1000
> ?char ?cs[CSSIZE+20]; ?/* text string converted into this */
> /n/sources/plan9//sys/src/cmd/eqn/text.c:42,48 - text.c:43,49
> ? ? ? ?wchar_t r;
> ? ? ? ?int w;
>
> - ? ? ? w = mbtowc(&r, psp, 3);
> + ? ? ? w = mbtowc(&r, psp, UTFmax);
> ? ? ? ?if(w == 0){
> ? ? ? ? ? ? ? ?psp++;
> ? ? ? ? ? ? ? ?return 0;
> /n/sources/plan9//sys/src/cmd/eqn/text.c:49,55 - text.c:50,56
> ? ? ? ?}
> ? ? ? ?if(w < 0){
> ? ? ? ? ? ? ? ?psp += 1;
> - ? ? ? ? ? ? ? return 0x80; ? ?/* Plan 9-ism */
> + ? ? ? ? ? ? ? return Runeerror; ? ? ? /* Plan 9-ism */
> ? ? ? ?}
> ? ? ? ?psp += w;
> ? ? ? ?return r;
> /n/sources/plan9//sys/src/cmd/eqn/text.c:112,128 - text.c:113,125
> ? ? ? ?printf(".ds %d \"%s\n", yyval, p);
> ?}
>
> - int isalpharune(int c)
> - {
> - ? ? ? return ('a'<=c && c<='z') || ('A'<=c && c<='Z');
> - }
> -
> ?int isdigitrune(int c)
> ?{
> ? ? ? ?return ('0'<=c && c<='9');
> ?}
>
> - trans(int c, char *p1)
> + int
> + trans(int c, char *)
> ?{
> ? ? ? ?int f;
>
> /n/sources/plan9//sys/src/cmd/eqn/tuning.c:146,151 - tuning.c:146,155
> ? ? ? ? ? ? ? ?target = &Subbase;
> ? ? ? ?else if (eq(s, "Supshift"))
> ? ? ? ? ? ? ? ?target = &Supshift;
> + ? ? ? else{
> + ? ? ? ? ? ? ? ERROR "unknown ftune" FATAL;
> + ? ? ? ? ? ? ? return;
> + ? ? ? }
> ? ? ? ?if (t[0] == '+' || t[0] == '-')
> ? ? ? ? ? ? ? ?*target += f;
> ? ? ? ?else
>

[9fans] p9p troff/ps problem, comparison with heirloom

[erik quanstrom]

> So what problem should your change remove? (I am sorry it's not clear
> to me from your code.)

you should not see eqn eating runes after this patch.

- erik

[9fans] p9p troff/ps problem, comparison with heirloom

[Rudolf Sykora]

> The problems I have described exist in plan9port and heirloom
> software. I haven't yet tried to what extent it also applies to plan9
> proper. And it seems you are suggesting some changes to the latter
> software.

As I have tried, I really don't see any of the mentioned problems when
using my plan9 machine directly; I only see the problems in the p9p
and heirloom troff.

Further, when I take the directory /sys/lib/postscript/font from plan9
and copy it to (replace with it) the contents of p9p's
$PLAN9/postscript/font I get a result quite similar to the previously
shown output of the heirloom suite, i.e., everything is present,
however the square-root sign is wrongly placed.

If you know any reason why the square-root symbol is ok on p9 and
wrong on p9p (or also how to get it right), please tell...

Thank you,
Ruda

PS.: The story shows that even when using Times Roman, some (quite
usual) letters (like em-dash, dagger,...) are taken from Lucida Sans.
This isn't particularly nice.

[9fans] p9p troff/ps problem, comparison with heirloom

[Rudolf Sykora]

On 11 November 2011 19:38, Rudolf Sykora <rudolf.sykora at gmail.com> wrote:

> Further, when I take the directory /sys/lib/postscript/font from plan9
> and copy it to (replace with it) the contents of p9p's
> $PLAN9/postscript/font I get a result quite similar to the previously
> shown output of the heirloom suite, i.e., everything is present,
> however the square-root sign is wrongly placed.

The story is more complicated... :(

Even though I see some placement on screen (in gv or page) I get a
different result when printed. E.g., the on screen wrongly placed sqrt
sign gets printed ok, while one of the big brackets though good on
screen prints wrongly. Furthermore, now page displays different things
than gv.

I hoped that with postscript one can achieve the same results
everywhere, but it actually seems difficult...

Ruda

[9fans] p9p troff/ps problem, comparison with heirloom

[Gorka Guardiola]

On Nov 11, 2011, at 8:06 PM, Rudolf Sykora <rudolf.sykora at gmail.com> wrote:
> screen prints wrongly. Furthermore, now page displays different things
> than gv.
> 
> I hoped that with postscript one can achieve the same results
> everywhere, but it actually seems difficult...

When this happens to me, normally it is because I did not download the fonts into the document.

See:

http://plan9.bell-labs.com/wiki/plan9/fonts/index.html

HTH

G.

[9fans] p9p troff/ps problem, comparison with heirloom

[Rudolf Sykora]

On 11 November 2011 21:02, Gorka Guardiola <paurea at gmail.com> wrote:
> When this happens to me, normally it is because I did not download the fonts into the document.

I have believed this is taken care of by the psfonts command on p9p.
As this is actually perhaps an interesting question on its own: Is
there any simple way to check which fonts are used in a ps and whether
there are all relevant fonts downloaded (embedded) in it?

Thanks
Ruda

Re: [9fans] p9p troff/ps problem, comparison with heirloom

[Rudolf Sykora]

On 11 November 2011 20:06, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
> On 11 November 2011 19:38, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
>
>> Further, when I take the directory /sys/lib/postscript/font from plan9
>> and copy it to (replace with it) the contents of p9p's
>> $PLAN9/postscript/font I get a result quite similar to the previously
>> shown output of the heirloom suite, i.e., everything is present,
>> however the square-root sign is wrongly placed.
>
> The story is more complicated... :(
>
> Even though I see some placement on screen (in gv or page) I get a
> different result when printed. E.g., the on screen wrongly placed sqrt
> sign gets printed ok, while one of the big brackets though good on
> screen prints wrongly. Furthermore, now page displays different things
> than gv.
>
> I hoped that with postscript one can achieve the same results
> everywhere, but it actually seems difficult...
>
> Ruda
>

It seems that quite a few problems I've been having are connected with
the lines which both dpost on plan9 or tr2post on p9p add to the
by-them created postscript. I find there lines like this:
-----------------------------
%
% A few arrays used to adjust reference points and character widths in some
% of the printer resident fonts. If square roots are too high try changing
% the lines describing /radical and /radicalex to,
%
%	/radical	[0 -75 550 0]
%	/radicalex	[-50 -75 500 0]
%
% Move braceleftbt a bit - default PostScript character is off a bit.
%

/Sdefs [
	/bracketlefttp		[201 500]
	/bracketleftbt		[201 500]
	/bracketrighttp		[-81 380]
	/bracketrightbt		[-83 380]
	/braceleftbt		[203 490]
	/bracketrightex		[220 -125 500 0]
	/radical		[0 0 550 0]
	/radicalex		[-50 0 500 0]
	/parenleftex		[-20 -170 0 0]
	/integral		[100 -50 500 0]
	/infinity		[10 -75 730 0]
] def

/S1defs [
	/underscore		[0 80 500 0]
	/endash			[7 90 650 0]
] def
-----------------------------

Apparently, somebody has tried to fine-tune placement of certain
characters. E.g., the bottom part of a left brace (/braceleftbt) seems
shifted by 2 points. Writing 201 500 into the relevant bracket solves
my problem with a broken left bracket...

This tuning can also stand behind the difference I see on the screen
and when the file is printed by a printer. Perhaps programs like gv
don't read these shifts and what they show is then different from what
gets printed.

Also it might explain why boxes' upper bars are not printed in their
due place, at least for me.

Ruda

[9fans] p9p troff/ps problem, comparison with heirloom

[Rudolf Sykora]

Hello,

In my new linux installation + p9p I found myself having problems with
using p9p troff.
To ilustrate, consider the input for troff

.\".do xflag 3
.\".lc_ctype en_US.utf8
em-dash:?
.br
brackets, big delta, sqrt:
.EQ
left ( { ?? - sqrt 2 } over 5? right )
.EN

which is then used with
9 eqn a | 9 troff | 9 tr2post | 9 psfonts > p9p.ps

The screenshot of the result is attached in p9p.png. You see no
em-dash, no big delta (tilde instead), the 1st half of the sqrt sign
missing and the second half wrongly positioned.

For comparison I supplied the same example, with uncommented fist two
lines, to Heirloom troff:
$HEIRLOOM/eqn a | $HEIRLOOM/troff | $HEIRLOOM/dpost > heirloom.ps
and the respective result is attached in heirloom.png.
In the heirloom case, the situation is better (em-dash, big delta, 1st
part of the sqrt is there), however, the second part of the sqrt is
still wrongly positioned.

If anyone can help me out of this mess, I'd be grateful!

Thank you
Ruda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p9p.png
Type: image/png
Size: 2362 bytes
Desc: not available
URL: <http://mail.9fans.net/private/9fans/attachments/20111111/93cea785/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: heirloom.png
Type: image/png
Size: 2514 bytes
Desc: not available
URL: <http://mail.9fans.net/private/9fans/attachments/20111111/93cea785/attachment-0001.png>