Re: Basic WYSIWYG printing in GNU Emacs (Arabic & Hebrew)

[Eli Zaretskii]

> From: Anand Tamariya <atamariya@gmail.com>
> Date: Thu, 12 Aug 2021 10:54:41 +0530
> Cc: emacs-devel@gnu.org
> 
>  So if the entire buffer uses just a single font, like TUTORIAL.he
>  does, you do the test only once, at the first character of the buffer
>  text?  But that could produce incorrect results, because the text
>  further into the buffer could have both RTL and LTR paragraphs
>  intermixed, and the correct display will show each of these at their
>  correct base direction.  For example, most of the paragraphs in
>  TUTORIAL.he have right-to-left base direction, but the last paragraph,
>  with the Local Variables, is left-to-right, so its display starts at
>  the left edge of the window.
> 
> Intermixed paragraphs are fine though mixed text is slightly problematic (see 
> attachment).

Yes, the problems with rendering mixed text are to be expected with
such simplistic handling of bidirectional text.

>  The window positioning information can only be obtained for the part
>  of the buffer text actually visible in a window; for buffer positions
>  outside of the viewport posn-at-point will give you nil.  How do you
>  work around this limitation to allow printing text of the entire
>  buffer?
> 
> You are correct with your doubts. And unfortunately, I don't have all the 
> answers. That's why in all my
> communication I've always maintained "Basic" WYSIWYG. Maybe somebody else can 
> improve upon the
> algorithm.

OK, thanks.

I think a better way of doing this job is to implement a PS display
back-end, similar to the X, w32, and NS back-ends we have now (see
xterm.c, w32term.c, nsterm.m), but one which would emit PS code to
print stuff on a paper page of known dimensions, instead of showing it
on the screen.  Then the bidi reordering will be taken care of by the
display code without any additional efforts, and we will be free from
the limitations of having the buffer displayed in its entirety in a
window etc.  Unfortunately, this means most of the job will have to be
in C, not in Lisp.

Since you know much more than I do about PostScript and PS printers,
may I ask you a question: if one sends RTL text embedded in a PS
program to a PS printer, does the printer have the capability to
reorder RTL text when it prints it?  That is, if you send a string of
RTL characters that way, are they printed in reverse order?  Or do PS
printers need the text in the "visual" order, already reordered for
display?