mlterm-dev-en — mlterm mailing list(English)

Re: [Mlterm-dev-en] mlterm config

[Araki K. <ara...@us...>]

 Hi,

From: Mayuresh <may...@ac...>
Subject: Re: [Mlterm-dev-en] mlterm config
Date: Sat, 18 Jan 2014 13:53:17 +0530
Message-ID: <201...@SD...>

> On Sat, Jan 18, 2014 at 02:14:56AM +0900, Araki Ken wrote:
> >  I fixed these bugs, so try hg head.
> >  => https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz
> 
> I get the following error when trying to compile the above on tiny core
> linux. Any leads?
> 
> libtool: link: `x_font_xft.lo' is not a valid libtool object
> make[1]: *** [libtype_xft.la] Error 1
> make: *** [all] Error 2

 Will you send me a log file of ./configure and make ?


 If you have cygwin 1.7 environment,
 http://mlterm.sourceforge.net/mlterm-cygwin17-20140121.zip
 (http://mlterm.sf.net/bin.html) is also available.
 This archive contains executable binaries of the latest mlterm.

 (Usage) Install DVYG0ntt.ttf.
         Get http://mlterm.sourceforge.net/mlterm-cygwin17-20140121.zip and
	     http://mlterm.sourceforge.net/main.indic
	 Setup as follows.
         $ cd / ; unzip foo/bar/mlterm-cygwin17-20140121.zip
           => install binaries to /bin, /etc and /lib/mlterm.
	 $ cp foo/bar/main.indic ~/.mlterm/main
	 $ mlterm

 BTW, I fixed additional rendering problems, and updated
https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Sat, Jan 18, 2014 at 02:14:56AM +0900, Araki Ken wrote:
>  I fixed these bugs, so try hg head.
>  => https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz

I get the following error when trying to compile the above on tiny core
linux. Any leads?

libtool: link: `x_font_xft.lo' is not a valid libtool object
make[1]: *** [libtype_xft.la] Error 1
make: *** [all] Error 2

Mayuresh.

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Sat, Jan 18, 2014 at 02:14:56AM +0900, Araki Ken wrote:
>  If you know some examples of console applications rendering indic scripts
> correctly on a terminal, please inform me of them.

I can give an example of elinks. As of mlterm I am able to run, it shows
only some of the letters on this page in devnagari and rest all as
asterisks. Let me know whether you see full page in devnagari.
http://maharashtratimes.indiatimes.com/newsletter.cms


I have another question with X11 itself. If I select devnagari text from
firefox and paste it in mlterm, it just shows ????. What could be the
reason?


>  BTW, I found some mlterm bugs of rendering indic scripts.
>  Mainly, mlterm converts unicode indic scripts to ISCII ones internally, but
> U+950 - U+95e weren't correctly converted to ISCII because each of these characters
> is equivalent to *two* ISCII characters. (Some unicode characters (e.g. U+960 -
> U+963 etc) which I couldn't find equivalent ISCII characters are still untouched.)

Can you elaborate this a little bit. If it is a script related question,
if you can give me some steps, I can definitely help.

>  I fixed these bugs, so try hg head.
>  => https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz

Will try.

>  The difference between 3.3.2 and hg head is http://mlterm.sf.net/mlterm-fixindic.png

I saw the screenshot. That is a remarkable improvement. Hope we get it in
the next release soon. (I'll try head for now.)

> PS: If you find text files which pango-view and mlterm show differently, please
>     send it to me.

I can say pango-view and firefox render devnagari nearly perfectly. So if
you are not familiar with the script and see a garbled character I am
nearly sure you can trust the rendering of these two.

I could cite a lot of text that was correct with pango-view and incorrect
with mlterm. But after seeing your screenshot, I feel a lot of it might be
taken care of. I'll try with head and let you know if I find
discrepancies.

Mayuresh

Re: [Mlterm-dev-en] mlterm config

[Araki K. <ara...@us...>]

 Hi,

From: Mayuresh <may...@ac...>
Subject: Re: [Mlterm-dev-en] mlterm config
Date: Tue, 14 Jan 2014 09:13:17 +0530
Message-ID: <201...@SD...>

> How does a tool like pango-view or firefox render devanagari correctly? Is
> it possible to adopt what they do?

 I think it uses pango to render devanagari.
 I'm sorry but I haven't figured out how and where pango renders devanagari yet.

 Mlterm doesn't need full pango library but needs the conversion table from unicode
codepoints to font indexes.

> Would also like to understand the application's role in rendering. E.g.
> if I cat a file on the terminal it renders alright, but same in
> vi/more/less does not look the same, not in elinks either.

 Console applications usually assume that one unicode character should occupy one
fixed-width column in the terminal.
 This doesn't hold good for indic scripts which need complex text layout.
 It is difficult (impossible?) for console applications to determine how many
*columns* (not characters) should be overwritten or deleted in editing indic
scripts.

 If you know some examples of console applications rendering indic scripts
correctly on a terminal, please inform me of them.


 BTW, I found some mlterm bugs of rendering indic scripts.
 Mainly, mlterm converts unicode indic scripts to ISCII ones internally, but
U+950 - U+95e weren't correctly converted to ISCII because each of these characters
is equivalent to *two* ISCII characters. (Some unicode characters (e.g. U+960 -
U+963 etc) which I couldn't find equivalent ISCII characters are still untouched.)

 I fixed these bugs, so try hg head.
 => https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz

 The difference between 3.3.2 and hg head is http://mlterm.sf.net/mlterm-fixindic.png

 Regars,

PS: If you find text files which pango-view and mlterm show differently, please
    send it to me.
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Tue, Jan 14, 2014 at 07:49:51AM +0900, Araki Ken wrote:
>  I'll be happy if you report strange behaviors or bugs of libind conversion
> tables etc in detail or suggest alternative libraries.

One of the biggest problems is - vim not being able to render the
characters the way cat renders on mlterm. What could be the reason?

Mayuresh.

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Tue, Jan 14, 2014 at 07:49:51AM +0900, Araki Ken wrote:
>  libind converts ISCII text to the glyph indexes of such fonts as DVYG0ntt.ttf
> and DVSR0ntt.ttf which contain glyphs in a different order from modern unicode
> fonts.
> * The glyphs in DVG0ntt.ttf is http://mlterm.sf.net/ttyogesh-glyphs.png
> * The conversion table from ISCII hindi text to the glyph indexes is
>   https://bitbucket.org/arakiken/mlterm/src/tip/libind/table/hindi.table
> 
>  I'm not familiar with indic scripting, but I think the current processing
> depending on libind is obsolete.
>  I would like to change it to the modern and light-weight alternative
> if available.
> 
>  I'll be happy if you report strange behaviors or bugs of libind conversion
> tables etc in detail or suggest alternative libraries.

I am not sure how to check the tables. What are the rectangular boxes in
the glyphs? I see those often in mlterm. Many of them could be incorrect.
http://mlterm.sf.net/ttyogesh-glyphs.png

There are some other glyph based fonts, which look cleaner. I'll try these
and provide feedback whether they do better than ttyogesh in mlterm.
https://www.typotheque.com/fonts/fedra_hindi/book/glyphs

BTW Would looking at this code used by lexilogos help you in any way?
http://www.lexilogos.com/clavier/cardeva.js


Mayuresh

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Tue, Jan 14, 2014 at 11:10:09AM +0100, Fran?ois Patte wrote:
> As far as I understand, the use of mlterm with indic scripts, needs to
> enter iscii code in mlterm which will return glyphs from an appropriate
> font; am I right?

Input method is another dimension altogether. First problem that appears
to me is of correct rendering.

BTW, as input method I prefer online itrans method:
http://www.lexilogos.com/keyboard/devanagari.htm

I have never got to work scim or anything like that work (on NetBSD that
is).

Mayuresh

Re: [Mlterm-dev-en] mlterm config

[François P. <fra...@mi...>]

Le 13/01/2014 23:49, Araki Ken a écrit :
>  Hi,
> 
>  Thanks for your obvervations.
> 
> From: Mayuresh <may...@ac...>
> Subject: Re: [Mlterm-dev-en] mlterm config
> Date: Mon, 13 Jan 2014 08:55:53 +0530
> Message-ID: <201...@SD...>
> 
>> 3. There are more popular fonts such as Lohit Marathi, which strangely do
>> not work. I wonder whether the space in their name is a problem.
> 
>  Lohit Marathi font doesn't have glyphs to render ISCII text by libind.
> 
>> 7. Lastly, the rendering is very approximate and has several limitations.
>> It is better than some of the other terminals but inferior to what a web
>> browser, office or even what a tool like pango-view shows.
> 
>  The support of indic scripts depends on libind library which was developed
> 15 years ago.
> 
>  libind converts ISCII text to the glyph indexes of such fonts as DVYG0ntt.ttf
> and DVSR0ntt.ttf which contain glyphs in a different order from modern unicode
> fonts.

As far as I understand, the use of mlterm with indic scripts, needs to
enter iscii code in mlterm which will return glyphs from an appropriate
font; am I right?

So the problem is: how to enter iscii code using ibus and m17n
libraries? I did not find any iscii input method in iBus...

And the use of unicode fonts like FreeSerif is (up to now) impossible.


Regards



-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)1 8394 5849
http://www.math-info.univ-paris5.fr/~patte

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Tue, Jan 14, 2014 at 07:49:51AM +0900, Araki Ken wrote:
> > 7. Lastly, the rendering is very approximate and has several limitations.
> > It is better than some of the other terminals but inferior to what a web
> > browser, office or even what a tool like pango-view shows.
> 
>  The support of indic scripts depends on libind library which was developed
> 15 years ago.
> 
>  libind converts ISCII text to the glyph indexes of such fonts as DVYG0ntt.ttf
> and DVSR0ntt.ttf which contain glyphs in a different order from modern unicode
> fonts.
> * The glyphs in DVG0ntt.ttf is http://mlterm.sf.net/ttyogesh-glyphs.png
> * The conversion table from ISCII hindi text to the glyph indexes is
>   https://bitbucket.org/arakiken/mlterm/src/tip/libind/table/hindi.table
> 
>  I'm not familiar with indic scripting, but I think the current processing
> depending on libind is obsolete.
>  I would like to change it to the modern and light-weight alternative
> if available.
> 
>  I'll be happy if you report strange behaviors or bugs of libind conversion
> tables etc in detail or suggest alternative libraries.

I am really enthused by your mail.  I have been desperately looking for a
devanagari terminal for ages now and asked nearly every possible mailing
list and contact.

If there is anything I can do to improve mlterm's support for indic, I'll
be glad. I'll take a look at above links, though have a basic question.
How does a tool like pango-view or firefox render devanagari correctly? Is
it possible to adopt what they do?

Would also like to understand the application's role in rendering. E.g.
if I cat a file on the terminal it renders alright, but same in
vi/more/less does not look the same, not in elinks either.

mutt, elinks and vim are the 3 applications that matter to my day to day
usage a lot.

Mayuresh.

Re: [Mlterm-dev-en] mlterm config

[Araki K. <ara...@us...>]

 Hi,

 Thanks for your obvervations.

From: Mayuresh <may...@ac...>
Subject: Re: [Mlterm-dev-en] mlterm config
Date: Mon, 13 Jan 2014 08:55:53 +0530
Message-ID: <201...@SD...>

> 3. There are more popular fonts such as Lohit Marathi, which strangely do
> not work. I wonder whether the space in their name is a problem.

 Lohit Marathi font doesn't have glyphs to render ISCII text by libind.

> 7. Lastly, the rendering is very approximate and has several limitations.
> It is better than some of the other terminals but inferior to what a web
> browser, office or even what a tool like pango-view shows.

 The support of indic scripts depends on libind library which was developed
15 years ago.

 libind converts ISCII text to the glyph indexes of such fonts as DVYG0ntt.ttf
and DVSR0ntt.ttf which contain glyphs in a different order from modern unicode
fonts.
* The glyphs in DVG0ntt.ttf is http://mlterm.sf.net/ttyogesh-glyphs.png
* The conversion table from ISCII hindi text to the glyph indexes is
  https://bitbucket.org/arakiken/mlterm/src/tip/libind/table/hindi.table

 I'm not familiar with indic scripting, but I think the current processing
depending on libind is obsolete.
 I would like to change it to the modern and light-weight alternative
if available.

 I'll be happy if you report strange behaviors or bugs of libind conversion
tables etc in detail or suggest alternative libraries.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm config

[Mayuresh <may...@ac...>]

On Sun, Jan 12, 2014 at 11:51:06PM +0100, Fran?ois Patte wrote:
> Now I am wondering how to run mlterm to display indic scripts: I can use
> iBus, but if I use harvard-tokyo input method through iBus, mlterm
> cannot display the devanagari script.
> 
> How can I configure mlterm to use otf fonts like FreeSerif which is able
> to display both roman and devanagari?

I have some observations about devanagari on mlterm

1. The command that worked for me is:
mlterm --bi=false --ind -E utf8 -V --type=cairo -w 24
with ~/.mlterm/aafont containing ISCII_HINDI= DV\-TTYogesh

2. -E isciihindi is a valid argument, though it does not work.
--type=cairo or xft, both work with some minor change in appearance.
It is important to watch .mlterm/msg.log to see whether there were any
rendering errors.

3. There are more popular fonts such as Lohit Marathi, which strangely do
not work. I wonder whether the space in their name is a problem.

4. README.indic in the package is handy.

5. I found this working only on Linux. I have been trying to get mlterm
work on NetBSD with no luck. It shows garbled fonts for exactly same build
and CLI arguments.

6. Rendering is also a function of the application. E.g. if I cat a file
on the terminal it renders better than it does the same file in vi. In a
browser like elinks, some devanagari text was shown fine while some was
not. If I cat a file through paging commands like more/less, it doesn't
render it properly.

7. Lastly, the rendering is very approximate and has several limitations.
It is better than some of the other terminals but inferior to what a web
browser, office or even what a tool like pango-view shows.

Mayuresh

[Mlterm-dev-en] mlterm config

[François P. <fra...@mi...>]

Bonsoir,

I have just compiled mlterm and I don't know how to use it with indic
scripts.

I run configure script like this:

./configure --enable-m17nlib --enable-ibus --with-type-engines=xft
--enable-ssh2 --enable-ind

And install mlterm without any problems.

Now I am wondering how to run mlterm to display indic scripts: I can use
iBus, but if I use harvard-tokyo input method through iBus, mlterm
cannot display the devanagari script.

How can I configure mlterm to use otf fonts like FreeSerif which is able
to display both roman and devanagari?


And is it possible to have many indian scripts at the same time:
devanagari, tamil, etc.

Thanks for any help.

-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)1 8394 5849
http://www.math-info.univ-paris5.fr/~patte

Re: [Mlterm-dev-en] A basic questions : fonts reside on X client or X server machine

[Araki K. <ara...@us...>]

 Hi,

From: Mayuresh <may...@ac...>
Subject: [Mlterm-dev-en] A basic questions : fonts reside on X client or X server machine
Date: Sat, 11 Jan 2014 08:48:14 +0530
Message-ID: <201...@SD...>

> I have been trying to get mlterm work for devanagari fonts.
> 
> My X11 server runs on NetBSD. mlterm on NetBSD failed to render devanagari
> fonts. So I am trying to launch mlterm from a Linux machine on the NetBSD
> X11 server.
> 
> A basic question I have is, the required fonts, locales etc. are necessary
> on which machine - client or the server, or which things are required
> where?
> 
> I am sure mlterm has to link with some libraries required for devanagari,
> so those should be on client. But what about the fonts? Aren't they
> required on the X11 server's machine?

 If you use true type fonts by xft or cairo, it is necessary to install
them to the client machine.
 So please setup xft or cairo and devanagari fonts on your NetBSD box
before building and starting mlterm.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Truecolor - Support for 16 million colors

[Araki K. <ara...@us...>]

 Hi,

From: XVilka Haos of System <xv...@gm...>
Subject: [Mlterm-dev-en] Truecolor - Support for 16 million colors
Date: Fri, 10 Jan 2014 06:57:43 +0400
Message-ID: <CA+8M6w=JVMfgKRm4fJbYB=g+N...@ma...>

> Here's a test case
> 
> printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"
> 
> According to Wikipedia[1], this is only supported by xterm and konsole.

 Mlterm has supported this sequence since 3.1.6. (about one year ago)
 But it doesn't show 24 bit colors at the same time but searches the closest
color from 256 color palette. Xterm works in the same way.

 I think it won't cause problems in most cases except image processing
like sixel graphics.

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] A basic questions : fonts reside on X client or X server machine

[Mayuresh <may...@ac...>]

I have been trying to get mlterm work for devanagari fonts.

My X11 server runs on NetBSD. mlterm on NetBSD failed to render devanagari
fonts. So I am trying to launch mlterm from a Linux machine on the NetBSD
X11 server.

A basic question I have is, the required fonts, locales etc. are necessary
on which machine - client or the server, or which things are required
where?

I am sure mlterm has to link with some libraries required for devanagari,
so those should be on client. But what about the fonts? Aren't they
required on the X11 server's machine?

Mayuresh.

[Mlterm-dev-en] Support for True Color (16 millions colors)

[Антон К. <ant...@gm...>]

Here's a test case

printf "\x1b[38;2;255;100;
0mTRUECOLOR\x1b[0m\n"

According to Wikipedia[1], this is only supported by xterm and konsole.

It's a common confusion about terminal colors... Actually we have this:

* plain ascii
* ansi escape codes (16 color codes with bold/italic and background)
* 256 color palette (216 colors+16gray + ansi) (colors are 24bit)
* 24bit true color (8*8*8 colors (aka 16 milion)

The 256 color palete is configured at start, and it's a 6*6*6 cube of
colors, each of them defined as a 24bit (8*8*8 rgb) color.

This means that current support can only display 256 *different* colors
in the terminal, while truecolor means that you can display 16 milion
different colors at the same time.

Truecolor escape codes doesnt uses a color palete. It just specifies the
color itself.

[1] https://en.wikipedia.org/wiki/ANSI_color

Here is another terminals discussions:

Now supporting truecolor:

st (from suckless) -  http://lists.suckless.org/dev/1307/16688.html
konsole (already fixed)  https://bugs.kde.org/show_bug.cgi?id=138740
all libvte based terminals:  https://bugzilla.gnome.org/show_bug.cgi?id=704449
sakura  https://bugs.launchpad.net/sakura/+bug/1202564
Also iterm2 have support for truecolor.

Not supporting truecolor:

urxvt -  http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001826.html

Best regards,
Anton Kochkov.

[Mlterm-dev-en] Truecolor - Support for 16 million colors

[XVilka H. of S. <xv...@gm...>]

Here's a test case

printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"

According to Wikipedia[1], this is only supported by xterm and konsole.

It's a common confusion about terminal colors... Actually we have this:

* plain ascii
* ansi escape codes (16 color codes with bold/italic and background)
* 256 color palette (216 colors+16gray + ansi) (colors are 24bit)
* 24bit true color (8*8*8 colors (aka 16 milion)

The 256 color palete is configured at start, and it's a 6*6*6 cube of
colors, each of them defined as a 24bit (8*8*8 rgb) color.

This means that current support can only display 256 *different* colors
in the terminal, while truecolor means that you can display 16 milion
different colors at the same time.

Truecolor escape codes doesnt uses a color palete. It just specifies the
color itself.

[1] https://en.wikipedia.org/wiki/ANSI_color

Here is another terminals discussions:

Now supporting truecolor:

st (from suckless) -  http://lists.suckless.org/dev/1307/16688.html
konsole (already fixed)  https://bugs.kde.org/show_bug.cgi?id=138740
all libvte based terminals:  https://bugzilla.gnome.org/show_bug.cgi?id=704449
sakura  https://bugs.launchpad.net/sakura/+bug/1202564
Also iterm2 have support for truecolor.

Not supporting truecolor:

urxvt -  http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001826.html

Best regards,
XVilka.

[Mlterm-dev-en] mlterm 3.3.2 released

[Araki K. <ara...@us...>]

 Hi,

 This is to announce the release of mlterm version 3.3.2

 http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.3.2/mlterm-3.3.2.tar.gz/download

 SHA1 (mlterm-3.3.2.tar.gz) = 035988a7e9440b3e44e9f0b210e4fe131d2056ee

Overview of changes from 3.3.1
===============================
ver 3.3.2
* Support 4bpp framebuffer on NetBSD/luna68k.
* Desynchronize ssh negotiation on cygwin or mingw.
* "inner_border" option accepts "[horizontal border],[vertical border]" format value.
* Add "leftward_double_drawing" option which embolds medium fonts by drawing doubly at
  1 pixel leftward instead of rightward.
* Add vte_terminal_set_color_*_rgba() functions to libvte compatible library.
* Bug fixes:
  Fix memory leak when opening pty fails on win32gdi.
  Fix the bug which disabled to clear hidden input method window it if large
  value is specified for --border option.
  Fix the bug which disabled to paste UTF-8 string.
  Bitbucket pull request #1 (Thanks to Hayaki Saito san)
  Fix the bug which causes segfault in pasting text via win32 clipboard from x11
  applications over ssh x11 forwarding
  Fix segfault caused by zero column characters like 0x200e.
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm 3.3.1 released

[Araki K. <ara...@us...>]

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: Re: [Mlterm-dev-en] mlterm 3.3.1 released
Date: Sat, 14 Dec 2013 10:01:47 -0800 (PST)
Message-ID: <138...@we...>

> Some time ago I’ve also noticed something strange about the width of the
> character cell when using Xft rendering (although I refrained from
> mentioning it since it wasn’t such a big deal), namely that it’s set too
> narrow by default.
> 
> I normally use DejaVu Sans Mono for Xft, and I have to adjust the width
> manually, e.g. for size 12 px I have to set PERCENT to about 113 in
> order to get the width I should expect, and for 13 px it should be set
> to 125. This happened with all the fonts I’ve tried, although they were
> not that many. Is there any way to make mlterm use a more adequate
> character width?

 https://bitbucket.org/arakiken/mlterm/commits/a557cbe93febdcc148798630b130ffd38bad0c3a
makes mlterm use the default character width of the loaded font.

> Also, what would you think of using point size instead of pixel size in
> the font specifications? Most stuff right now employs the latter more
> readily.

 Enabling point size has been already implemented.
 (All you have to do is call x_font_use_point_size_for_fc(1)
  https://bitbucket.org/arakiken/mlterm/src/tip/xwindow/xlib/x_font.c#cl-1258
  and x_font_set_dpi_for_fc(dpi)
  https://bitbucket.org/arakiken/mlterm/src/tip/xwindow/xlib/x_font.c#cl-1266)
 But it is enabled only when mlterm works as libvte compatible library
because gnome-terminal etc requires it.

 I hesitate to change the current default behavior, but I'll think of this
after 3.3.2 release.

 Regards,
--- 
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm 3.3.1 released

[Andi C. S. <ski...@ya...>]

Hello,

Thanks for the patch. I’m using GNU Unifont, the only widespread one
that I know of which does not have a bold variant (and it looks a lot
nicer now).

Some time ago I’ve also noticed something strange about the width of the
character cell when using Xft rendering (although I refrained from
mentioning it since it wasn’t such a big deal), namely that it’s set too
narrow by default.

I normally use DejaVu Sans Mono for Xft, and I have to adjust the width
manually, e.g. for size 12 px I have to set PERCENT to about 113 in
order to get the width I should expect, and for 13 px it should be set
to 125. This happened with all the fonts I’ve tried, although they were
not that many. Is there any way to make mlterm use a more adequate
character width?

Also, what would you think of using point size instead of pixel size in
the font specifications? Most stuff right now employs the latter more
readily.

Regards,
Andi Şerbănescu

Re: [Mlterm-dev-en] Some Confusion with Daemon Mode in mlterm and Reconnecting Session with mlclient

[Alexander S. <mai...@il...>]

On Sat, Dec 14, 2013, at 7:35, Araki Ken wrote:
>  Hi,
> 
> From: Alexander Stein <mai...@il...>
> Subject: [Mlterm-dev-en] Some Confusion with Daemon Mode in mlterm and
> Reconnecting Session with mlclient
> Date: Mon, 09 Dec 2013 08:11:11 +0300
> Message-ID:
> <138...@we...>
> 
>  Please add termtype=mlterm to ~/.mlterm/main.
> 
>  It seems somewhat confused indeed, but mlclient ignores the arguments of
> mlterm and applies those of mlclient alone.
>  So if you start mlterm with --term=mlterm and later start mlclient
>  without it,
> a new window mlclient opens has the default value (xterm) of termtype
> option.
> 
>  Write options which you usually use to ~/.mlterm/main, and specify
>  options
> you want to change temporarily as the arguments of mlclient.

Thanks so much for your response Araki.  I eventually figured this out
to be the case when I moved to a new feature that runs the daemon in
userspace, which improved environment variable usage and led me to
understand the mlclient options (via the config files) was the right way
to approach the problem.

Thanks again for taking the time to respond.

>  Regards,
> ---
> Araki Ken
> ara...@us...

Re: [Mlterm-dev-en] Some Confusion with Daemon Mode in mlterm and Reconnecting Session with mlclient

[Araki K. <ara...@us...>]

 Hi,

From: Alexander Stein <mai...@il...>
Subject: [Mlterm-dev-en] Some Confusion with Daemon Mode in mlterm and Reconnecting Session with mlclient
Date: Mon, 09 Dec 2013 08:11:11 +0300
Message-ID: <138...@we...>

> Hello,
> 
> I really like mlterm, and want to thank you guys for putting it out
> there.  I have been using it on and off for a few years now.  Currently,
> I am using mlterm on an Arch Linux laptop.
> 
> [me@laptop ~]$ uname -a
> Linux laptop 3.12.2-1-ARCH #1 SMP PREEMPT Fri Nov 29 21:14:15 CET 2013
> x86_64 GNU/Linux
> [me@laptop ~]$ mlterm -v
> mlterm version 3.3.1
> 
> When I run mlterm as a daemon in genuine mode, I run it using systemd
> (the Arch Linux default that replaces init and rc scripts).  I will
> avoid the details of that but I end up running the daemon with the
> following parameters.
> 
> mlterm --daemon=genuine --term=mlterm --ls=true --meta=esc --metakey=alt
> --display=:0.0
> 
> This seems to work fine, but I noticed some weird behavior in Emacs and
> other places because it was using xterm termcap defaults for the
> backspace key on my keybaord.  This is not what I intended.  I noticed
> that, even though mlclient seems to work, the $TERM variable was no
> longer `mlterm` as I had set it in my config, but it was now `xterm` in
> subsequent sessions and other configuration changes I made mlterm run in
> daemon mode as well.  Only the first mlclient that pops up sets up $TERM
> properly.
> 
> I noticed I can set --screens, but this pops up a number of screens and
> does not do what I intend.  Did I misunderstand what mlclient is capable
> of?  I thought I could reconnect to a session in genuine daemon mode (I
> did not even kill X11 yet) and reconnect to it with mlclient.  Currently
> I restart the daemon with systemd and I get what I want, but this is
> kind of silly.  Any thoughts?

 Please add termtype=mlterm to ~/.mlterm/main.

 It seems somewhat confused indeed, but mlclient ignores the arguments of
mlterm and applies those of mlclient alone.
 So if you start mlterm with --term=mlterm and later start mlclient without it,
a new window mlclient opens has the default value (xterm) of termtype option.

 Write options which you usually use to ~/.mlterm/main, and specify options
you want to change temporarily as the arguments of mlclient.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm 3.3.1 released

[Araki K. <ara...@us...>]

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: Re: [Mlterm-dev-ja] [Mlterm-dev-en] mlterm 3.3.1 released
Date: Thu, 5 Dec 2013 11:09:24 -0800 (PST)
Message-ID: <138...@we...>

> I would like to ask you about the algorithm which emboldens medium fontsto produce bold ones when no corresponding bold font is available or provided. Is is part of the mlterm code, or does it belong to some X font library?

 It is part of the mlterm code.

> Since it works by reduplicating pixels to the right and glyphs which have different width parity than the character cell tend to be shifted towards the right side more often than not, the resulting bold glyph will extend even more towards the right.

 Which font do you use ?
 I want to test it.

> I suggest, if possible, to add an option which alters the algorithm by shifting the resulting glyph 1 pixel leftwards (i.e. reduplicating pixels to the left) to preserve balance and prevent frequent overpassingof the character cell bounds.

 How about the attached patch ?
 Please apply it to hg head (http://bitbucket.org/arakiken/mlterm/get/tip.tar.gz),
build it and start mlterm with --ldd option.

> Another issue is the emboldening of semigraphic/block characters (specifically those in the 2580-299F range), which leads to distortion and loss of detail on the shades.I think these should not be touched by the algorithm at all. Can it be done?

 The attached patch includes this fix. Please test it.

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] Some Confusion with Daemon Mode in mlterm and Reconnecting Session with mlclient

[Alexander S. <mai...@il...>]

Hello,

I really like mlterm, and want to thank you guys for putting it out
there.  I have been using it on and off for a few years now.  Currently,
I am using mlterm on an Arch Linux laptop.

[me@laptop ~]$ uname -a
Linux laptop 3.12.2-1-ARCH #1 SMP PREEMPT Fri Nov 29 21:14:15 CET 2013
x86_64 GNU/Linux
[me@laptop ~]$ mlterm -v
mlterm version 3.3.1

When I run mlterm as a daemon in genuine mode, I run it using systemd
(the Arch Linux default that replaces init and rc scripts).  I will
avoid the details of that but I end up running the daemon with the
following parameters.

mlterm --daemon=genuine --term=mlterm --ls=true --meta=esc --metakey=alt
--display=:0.0

This seems to work fine, but I noticed some weird behavior in Emacs and
other places because it was using xterm termcap defaults for the
backspace key on my keybaord.  This is not what I intended.  I noticed
that, even though mlclient seems to work, the $TERM variable was no
longer `mlterm` as I had set it in my config, but it was now `xterm` in
subsequent sessions and other configuration changes I made mlterm run in
daemon mode as well.  Only the first mlclient that pops up sets up $TERM
properly.

I noticed I can set --screens, but this pops up a number of screens and
does not do what I intend.  Did I misunderstand what mlclient is capable
of?  I thought I could reconnect to a session in genuine daemon mode (I
did not even kill X11 yet) and reconnect to it with mlclient.  Currently
I restart the daemon with systemd and I get what I want, but this is
kind of silly.  Any thoughts?

Re: [Mlterm-dev-en] mlterm 3.3.1 released

[Andi C. S. <ski...@ya...>]

> Another issue is the emboldening of semigraphic/block characters (specifically those in the 2580-299F range), which leads to distortion and loss of detail on the shades. I think these should not be touched by the algorithm at all. Can it be done?


Sorry, I meant 2580-259F.