lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 May 2010 08:52:05 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Frank Pan <frankpzh@...il.com>
CC:	Alan Cox <alan@...ux.intel.com>,
	Gerardo Exequiel Pozzi <vmlinuz386@...oo.com.ar>,
	Kay Sievers <kay.sievers@...y.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Catalin Marinas <catalin.marinas@....com>,
	Daniel Mack <daniel@...aq.de>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>,
	Jochen Hein <jochen@...hen.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Dave Airlie <airlied@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Enlarge the storage of chars in virtual terminal

Hello,

On 05/27/2010 08:00 AM, Frank Pan wrote:
>> This has been suggested a couple of times but unfortunately it's not
>> enough to use bigger fonts. Rendering many non western languages is far
>> far more complex. In addition the text mode vt driver is limited to 512
>> symbols by the hardware.
>
> Why is it complex? IMHO Rendering non-western languages is nothing more than
> rendering 2 ASCII chars.

That's only true for CJK.  There are other scripts which are more
difficult to render properly.  e.g. In mixed English Arabic text,
English needs to be rendered left-to-right as usual while Arabic needs
to be rendered right-to-left.  Indic rendering is also known to be
very tricky.  Even on full desktop environment, only Gnome + Pango and
Visat/7 get everything right.

  http://en.wikipedia.org/wiki/Wikipedia%3AEnabling_complex_text_support_for_Indic_scripts

And then, if you think about multilingual terminal, output is only one
half of the story.  You gotta be able to input something too and in
many scripts, input handling needs to interact constantly with
rendering, which means that the kernel will also need to supply input
framework, at which point I start to wonder whether the whole thing is
just too complicated.

Why do we need a separate in-kernel implementation of unicode
rendering and multilingual input system at all?  What's the use case
other than "I just want to use console"?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ