mlterm-dev-ja Mailing List for mlterm(Multi Lingual TERMinal emulator)

 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...

> 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.

Hello,

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?

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.

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.

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?

Regards,
Andi Şerbănescu