emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Why is emacs so square?"


From: Arthur Miller
Subject: Re: "Why is emacs so square?"
Date: Fri, 05 Jun 2020 16:57:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Fri, 05 Jun 2020 15:01:13 +0200
>> Cc: sb@dod.no, emacs-devel@gnu.org
>> 
>> Anyway what about if emacs had a print-page-mode as a minor mode for
>> displaying some printing hints in text modes? I am not sure if I can
>> write such, but here is idea:
>> 
>> * provide a database of predefined paper sizes as specified on:
>>   https://www.papersizes.org/a-sizes-in-pixels.htm
>>   to be used as templates for width and height (in pixels)
>>   
>> * advice insert funcion(s) to check for current line pixel-width and
>>   pixel-height. If width or height exceed template width and height then
>>   insert ^L to denote page break and move point to next line and insert
>>   text in next line. If width is exceeded maybe it is just enough to
>>   move point to next line, but when height for a page is exceeded one
>>   would need a special char to visualize page break.
>> 
>> As I understand Emacs already has some support for page breaks (^L) as I
>> learned myself very recently :-). There is extended page handling in
>> Emacs and also a mode called PageMode:
>> 
>> https://www.emacswiki.org/emacs/PageMode
>> 
>> I am not sure, but what I think is missing is just to tie those things
>> to paper sizes and automize page creation based on some paper template
>> which is nothing but a pixel-width and pixel-height. I am not sure, I
>> haven't used PageMode myself, I just learned about it.
>> 
>> I am not sure how efficient it would be to check for pixel-width and height
>> on every char insertion, maybe there is some better way?
>
> All of this is already available, although not all of it is exposed to
> Lisp.  Taking advantage of existing pixel-level capabilities is part
> of the job of providing the features that Richard has in mind.
When you say all of this, and not exposed to lisp, what exactly do you
mean? :-) Is it possible to get a pixel offset from a point with elisp?
Height, width, or whatever that could be used to calculate if current
buffer region fits iin a page or not?

(defvar ppi-72
  '((4A0 . (4768 . 6741))
    (2A0 . (3370 . 4768))
    (A0  . (2384 . 3370))
    (A1  . (1684 . 2384))
    (A2  . (1191 . 1684))
    (A3  . (842  . 1191))
    (A4  . (595  . 842 ))
    (A5  . (420  . 595 ))
    (A6  . (298  . 420 ))
    (A7  . (210  . 298 ))
    (A8  . (147  . 210 ))
    (A9  . (105  . 147 ))
    (A10 . (74   . 105 ))))

If I have a database of sizes like this, I would need to know a size in
pixel of a buffer region between some min and max points. That could be
used to either defadvice insert or to calculate and restructure text
afterwards. Maybe it is to naive, no idea, just thinking. Also I am not
sure how resolution/ppi relate to emacs buffers to be honest.


>> It would be nice if Emacs could draw a thin line to denote edges, or a
>> rectangle of page size below the text as word processors do
>
> We already can display such thin lines, see, for example, help-fns.el
> (search for ":height").  No X-level graphics is needed.
As composed of characters or as overlays with underline/overstruck or
similar? What about a rectangle in some color as a background to
symbolize a page. I understand it is not needed, but it would be nice.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]