Re: Unicode box-drawing chars

Re: Unicode box-drawing chars

[Jesper Harder]

Oliver Scholz <alkibiades@gmx.de> writes:

> For example: I use adobe-courier for latin characters and gnu-unifont
> for everything else. Due to this in the following examples the "║"s on
> the right side are not properly aligned.

FWIW, all your examples look perfect for me.  I use Lucida Typewriter
for latin chars and 

    -Misc-Fixed-Medium-R-*--13-*-*-*-*-*-ISO10646-1

for everything else.

> Why do I ask and what do I want? There are many places where the
> box-drawing chars could be useful in Emacs.

Yeah, I use them to make a nice summary buffer in Gnus, e.g.

    Kai Großjohann          command.com versus cmd.exe
    ├╮ Klaus Berndl            
    │╰─╮ Kai Großjohann          
    │  ├╮ Klaus Berndl            
    │  ╰─╮ lawrence mitchell       
    ╰─╮ Zhongtao Zhu    

Re: Unicode box-drawing chars

[Kai Großjohann]

Oliver Scholz <alkibiades@gmx.de> writes:

> How do I deal with UCS box-drawing chars in Emacs? With the use of
> font-sets, it is very likely that the box-drawing chars and the
> latin-chars (and the Space) have different character width. So I can
> not rely on the box-drawing-chars being properly aligned.

Don't use characters of different width.

It seems that there is no way to really solve your problem, so one
might as well ignore it...

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Unicode box-drawing chars

[Kai Großjohann]

Jesper Harder <harder@myrealbox.com> writes:

> Yeah, I use them to make a nice summary buffer in Gnus, e.g.
>
>     Kai Großjohann          command.com versus cmd.exe
>     ├╮ Klaus Berndl            
>     │╰─╮ Kai Großjohann          
>     │  ├╮ Klaus Berndl            
>     │  ╰─╮ lawrence mitchell       
>     ╰─╮ Zhongtao Zhu    

Drool.

[x] send Lisp

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Unicode box-drawing chars

[Oliver Scholz]

This may be slightly off topic. It is, however, tangential.

How do I deal with UCS box-drawing chars in Emacs? With the use of
font-sets, it is very likely that the box-drawing chars and the
latin-chars (and the Space) have different character width. So I can
not rely on the box-drawing-chars being properly aligned.

For example: I use adobe-courier for latin characters and gnu-unifont
for everything else. Due to this in the following examples the "║"s on
the right side are not properly aligned.

  ╔════╗  
  ║    ║
  ║    ║
  ║    ║
  ║    ║
  ╚════╝

  ╔══════╗
  ║Dies  ║
  ║ist   ║
  ║ein   ║
  ║Test. ║
  ╚══════╝

Naturally things become even more strange in this example:

  ╔══╦══╗
  ║┌─╨─┐║
  ║│╲ ╱│║
  ╠╡ ╳ ╞╣
  ║│╱ ╲│║
  ║└─╥─┘║
  ╚══╩══╝

Why do I ask and what do I want? There are many places where the
box-drawing chars could be useful in Emacs. For example I could
imagine to enhance the widget-library to use those chars. Or Emacs/W3
could use them to render tables or whatever. Does anybody have an idea
how to deal with this problem?

    -- Oliver

-- 
26 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: Unicode box-drawing chars

[Roman Belenov]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Oliver Scholz <alkibiades@gmx.de> writes:
>
>> How do I deal with UCS box-drawing chars in Emacs? With the use of
>> font-sets, it is very likely that the box-drawing chars and the
>> latin-chars (and the Space) have different character width. So I can
>> not rely on the box-drawing-chars being properly aligned.
>
> Don't use characters of different width.

BTW Is there any way to prohibit W3 from changing family/weight of
fonts used ? Tables in rendered pages suffer from this "different
width" problem.

-- 
 							With regards, Roman.

Re: Unicode box-drawing chars

[Galen Boyer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 608 bytes --]

On Thu, 12 Sep 2002, Kai.Grossjohann@CS.Uni-Dortmund.DE wrote:
> Jesper Harder <harder@myrealbox.com> writes:
> 
>> Yeah, I use them to make a nice summary buffer in Gnus, e.g.
>>
>>     Kai GroÞ¿johann          command.com versus cmd.exe
>>     âž´ž¼âžµ® Klaus Berndl            
>>     âž´ž¢âžµ°âž´ž âžµ® Kai GroÞ¿johann          
>>     âž´ž¢  âž´ž¼âžµ® Klaus Berndl            
>>     âž´ž¢  âžµ°âž´ž âžµ® lawrence mitchell       
>>     âžµ°âž´ž âžµ® Zhongtao Zhu    
> 
> Drool.

I concur.

> [x] send Lisp

Please.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Re: Unicode box-drawing chars

[Jesper Harder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> Yeah, I use them to make a nice summary buffer in Gnus, e.g.
>>
>>     Kai Großjohann          command.com versus cmd.exe
>>     ├╮ Klaus Berndl            
>>     │╰─╮ Kai Großjohann          
>>     │  ├╮ Klaus Berndl            
>>     │  ╰─╮ lawrence mitchell       
>>     ╰─╮ Zhongtao Zhu    
>
> Drool.
>
> [x] send Lisp

It's pretty straight-forward:

(setq gnus-summary-line-format "%U%R%z %B%-23,23n %s\n")
(setq gnus-sum-thread-tree-root "")
(setq gnus-sum-thread-tree-single-indent "")
(setq gnus-sum-thread-tree-leaf-with-other "├╮ ")
(setq gnus-sum-thread-tree-vertical "│")
(setq gnus-sum-thread-tree-single-leaf "╰─╮ ")

It's a pitty we can't assume that everyone has a unicode font, so we
could make some attractive defaults in Gnus.  

Hmm, the tree display could probably also be made to look a lot prettier
than today with some box-drawing glyphs.

xpost & fu² gnu.emacs.gnus

Re: Unicode box-drawing chars

[Oliver Scholz]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Oliver Scholz <alkibiades@gmx.de> writes:
>
>> How do I deal with UCS box-drawing chars in Emacs? With the use of
>> font-sets, it is very likely that the box-drawing chars and the
>> latin-chars (and the Space) have different character width. So I can
>> not rely on the box-drawing-chars being properly aligned.
>
> Don't use characters of different width.
>
> It seems that there is no way to really solve your problem, so one
> might as well ignore it...
[...]

Well, actually I am not sure what my problem is, myself. I just happen
to browse through the Unicode spec currently. I have read about the
box drawing characters there and I wondered what we could do with them
in Emacs. Let's say, I'd like to explore the field of what could be
done and where the limitations lie.

It would be nice, if I could define a fontset in which the codepage
containing the box drawing chars (U+2500 to U+257f) are assigned to a
different font than the rest. So I could make sure that their width
matches the width of the default font.

But I guess, I was rather thinking of using those chars in Elisp
libraries. Suppose I want to make Emacs/W3 render tables with those
chars or to take another example: Suppose I want to write this
not-yet-existing function:

,----
| insert-in-box is an interactive compiled function in XXXXX.el
| (insert-in-box string width &optional position)
| 
| Insert STRING in a box drawn with UCS box drawing chars.
| WIDTH is the width of the box in characters. If optional third
| argument POSITION is an integer, insert the box at that buffer
| position. If it is a cons cell, the car is interpreted as the column
| and the cdr as the row. If it is omitted or nil, insert the box at
| point.
`----

What could I do to make sure, that this works as expected?

* Check for the width of the Latin font and the box drawing chars and
  scale the Unicode font if necessary

* Check for the width as above, but care for the proper alignment by
  inserting spaces after the Latin font. (IIRC Emacs allows for spaces
  of arbitrary width.)

* Both of the above, because the two fonts could have a different
  geometry at all.

* Ignore the problem and hope that the sizes match. I guess I partly
  asked my question, because I wanted to know how likely this is to
  happen. Maybe it is not correct for me only because my setup is
  weird?

* Maybe the box-drawing chars are not the right thing for this job?
  Perhaps it's better to generate pbm or xpm graphics on the fly and
  use them? AFAIK XEmacs supports images in display-tables. So this
  would be a lot easier in XEmacs than in Emacs. Or am I missing
  something?

* Use the classical "+", "-" and "|" from ascii by default, but
  provide a variable, so that the user can enable the Unicode-drawing.

Hmpf, I guess the last option would be the easiest and the most common
solution. But this would mean that we can not provide nice graphics as
a default. What a pity.

    -- Oliver, who wants more graphics and more eyecandy in Emacs

-- 
26 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: Unicode box-drawing chars

[Oliver Scholz]

Jesper Harder <harder@myrealbox.com> writes:
[...]
> It's a pitty we can't assume that everyone has a unicode font, so we
> could make some attractive defaults in Gnus.  

Yes. And even when there is a unicode font, it is quite possible that
it does not contain the box-drawing glyphs.

Is it possible to check from lisp if a font actually contains a glyph?

> Hmm, the tree display could probably also be made to look a lot prettier
> than today with some box-drawing glyphs.

I fancy some additional widgets for widget.el, too. Common GUI-stuff
like a tree-widget or tabs ... all done in plain text with the
box-drawing chars.

> xpost & fu² gnu.emacs.gnus

Ignored, because my question is not specific to Gnus.

    -- Oliver

-- 
27 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: Unicode box-drawing chars

[Kai Großjohann]

Oliver Scholz <alkibiades@gmx.de> writes:

> * Check for the width as above, but care for the proper alignment by
>   inserting spaces after the Latin font. (IIRC Emacs allows for spaces
>   of arbitrary width.)

Maybe it's possible to just draw pixels in Emacs?  If not, that might
be a useful addition.  Then you ask Emacs about the width in pixels
of the text and draw some lines for the box.

Maybe something has to be added to the display engine for this to
work.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Graphics in Emacs (was: Unicode box-drawing chars)

[Stefan Monnier <foo@acm.com>]

> A few months ago someone posted a patch in gnu.emacs.sources that
> allows to draw pixels immediately on the screen. This would allow
> basic vector graphics in Emacs. I'd like to see that included to.

Problem is that it was hopelessly broken since it did not hook into
the redisplay loop (i.e. the pixels were overwritten at every C-l).


        Stefan

Graphics in Emacs (was: Unicode box-drawing chars)

[Oliver Scholz]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Oliver Scholz <alkibiades@gmx.de> writes:
>
>> * Check for the width as above, but care for the proper alignment by
>>   inserting spaces after the Latin font. (IIRC Emacs allows for spaces
>>   of arbitrary width.)
>
> Maybe it's possible to just draw pixels in Emacs?  If not, that might
> be a useful addition.  Then you ask Emacs about the width in pixels
> of the text and draw some lines for the box.

Well, it is already possible to generate images on the fly. This --
for example -- is from my recent experiments:

(defun egoge-make-xpm-hbar (&optional width height colour)
  (or width (setq width (frame-char-width)))
  (or height (setq height (frame-char-height)))
  (or colour (setq colour (face-attribute 'default :foreground)))
  (find-image `((:type xpm :ascent center
		       :data ,(egoge-make-xpm-hbar-data width height colour)))))


(defun egoge-make-xpm-hbar-data (width height colour)
  (let ((bar-line (truncate (/ height 2)))
	(list nil)
	(count 0))
    (while (< count height)
      (if (= count bar-line)
	  (push (make-string width ?o) list)
	(push (make-string width ?\ ) list))
      (setq count (1+ count)))
    (concat "/* XPM */\n"
	    "static char *noname[] = {\n"
	    (format "\"%d %d 2 1\",\n" width height)
	    "/* colors */\n"
	    "\"  c None\",\n"
	    (format "\"o c %s\",\n" colour)
	    "/* pixels */\n"
	    "\"" (mapconcat 'identity list "\",\n\"") "\"};")))

[It would be better to use XBM or PBM instead of XPM, but I don't know
the according specs offhand.]

Now `(insert-image (egoge-make-xpm-hbar))' inserts a horizontal
bar XPM-image with the width and height of the default font. This is,
of course, very kludgy. It is somehow strange to create a string that
is supposed to be the equivalent of an XPM-file and then to make an
image from that string. It would be nice if Emacs provided some means
to do something like this immediately. This could help to develop all
kind of fancy GUI stuff.

And while I am dreaming:

A few months ago someone posted a patch in gnu.emacs.sources that
allows to draw pixels immediately on the screen. This would allow
basic vector graphics in Emacs. I'd like to see that included to.

For what would it be useful? I don't know yet. I am pretty sure that
someone would invent something useful or playful, if this feature were
available. I am pretty sure, that I would invent something ... :-)

One thing come to my mind: DrScheme, the editor for PLT Scheme,
provides a nice feature with vector graphics: If you hold the
mouse-pointer over a symbol in the argument-list of a function,
DrScheme draws a line from this symbol to all further occurences in
the function definition. This is supposed to help programming-newbies
to see what happens where with their arguments.

[And Emacs is supposed to be friendly to programming-newbies, too.]

> Maybe something has to be added to the display engine for this to
> work.
[...]

*sigh* To be sure, Emacs is the most wonderful application in the
 world. But there is so much missing, yet.

It is a pity that a general-purpose application is so bad at dealing
with images. ;-)

    -- Oliver

-- 
28 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: Unicode box-drawing chars

[Jesper Harder]

Oliver Scholz <alkibiades@gmx.de> writes:

> Yes. And even when there is a unicode font, it is quite possible that
> it does not contain the box-drawing glyphs.
>
> Is it possible to check from lisp if a font actually contains a glyph?

This isn't a very good solution (and it'll only work on X11):

You can determine which font Emacs will use with `internal-char-font'.
You could then call

    xlsfonts -lll -fn FONT

and parse the output to get the font metrics.  If the metrics for a
particular code point contains all zeros, say

           0x009f (159)	   0     0     0     0     0  0x0000  .

then the glyph doesn't exist in this font.

Re: Graphics in Emacs (was: Unicode box-drawing chars)

[Oliver Scholz]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

>> A few months ago someone posted a patch in gnu.emacs.sources that
>> allows to draw pixels immediately on the screen. This would allow
>> basic vector graphics in Emacs. I'd like to see that included to.
>
> Problem is that it was hopelessly broken since it did not hook into
> the redisplay loop (i.e. the pixels were overwritten at every C-l).

Hmm, what a pity. Is this only a problem with `recenter' or does this
affect -- for example -- scrolling, too?

Emacs is not able to display an image behind some text, is it? (I have
not yet installed the CVS version. I will do it soon, but I am short
of disk space at the moment.)

If it were, and if we had a function to change images directly, we
could use this for simple vector graphics.

Let me expand a bit on the functions to change an image directly that
I asked for in my previous mail. Pardon me, if the following
suggestion is silly. I don't know anything about Emacs's internals and
anything but Elisp is pure Sanskrit to me.

As I understand it, when a function inserts an image via an image
specifier, Emacs creates that image in the image cache from the data
in the specifier. If a function uses the same image-specifier again
("the same" meaning `eq' here), Emacs uses the same object in the
image cache again.

Now I would like to have a way to a) create an empty image, and b) a
way to set a pixel in an image in the image cache directly. For
example:

`make-image width height' creates an empty image in the image cache
and returns an image specifier for that image.

`set-pixel image x y colour' sets a pixel at position X, Y to colour
COLOUR. IMAGE is an image-specifier.

As I said, this could be useful for some fancy widgets in Emacs. I
have written some proof-of-concept code yesterday (see below). It goes
the kludgy way by creating an XPM-data-string. The code became a bit
longer as I expected. I post it here, though, and not in
gnu.emacs.sources, because it is not intended to be used but as a
demonstration in this discussion.

Test it like this:

(progn
  (switch-to-buffer (generate-new-buffer "*Test*"))
  (egoge-insert-in-box "Dies ist nichts weiter als ein blöder Test." 20 20 10))


    -- Oliver


[-- Attachment #2: make-xpm-box.el --]
[-- Type: application/emacs-lisp, Size: 9969 bytes --]

[-- Attachment #3: Type: text/plain, Size: 72 bytes --]


-- 
29 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!