emacs-devel
[Top][All Lists]
Advanced

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

Re: A patch for enforcing double-width CJK character display


From: 黄建忠
Subject: Re: A patch for enforcing double-width CJK character display
Date: Thu, 12 Apr 2012 19:18:39 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120327 Thunderbird/10.0.2

于 2012年04月12日 17:53, Eli Zaretskii 写道:
Date: Thu, 12 Apr 2012 16:56:16 +0800
From: 黄建忠<address@hidden>
Cc: address@hidden

FRAME_COLUMN_WIDTH and FRAME_SPACE_WIDTH never changed, it only be
initialized when first font loaded.
Right, and that's by design.
Can be understood, since the width/height of a lot of UI components was 
determined via these values.


Can anybody provide a clue how to catch the new width of default font
via FRAME_PTR when scale happened?
I don't think there is a way to do that, if all you have is the frame
pointer.  text-scale-mode does not modify the frame's default font, it
remaps the 'default' face to another face which specifies a larger or
a smaller font.  So the way to find the width of the font after
scaling is to get hold of the font itself, or of the face to which
'default' was remapped.  Then you can use FONT_WIDTH, I think (but I
didn't test this).
I can get the default font(the first font loaded when frame be initialized) via FRAME_FONT, it's great that it can not be changed after first font loaded. But I still can not get the current width after scale, since the props of FRAME_FONT also not be changed.

Since FRAME_FONT always return the initial value, FONT_WIDTH defined in xterm.h and FONT_WIDTH_NUMERIC defined in font.h DO works but only get the initial value of font width.

Of couse a new FcPattern can be created, the family of default font and the pixel_size of current loaded font can be set to the newly created FcPattern, After a FcPatternMatch call , width/average_width can be caculated. But since this function will be involked by "xftfont_text_extents" and "xftfont_draw" many many times, It should not be too complex and time consuming, Otherwise it will affect the performance of font drawing.

The problem exist in current patch is the "global variable" and a "dirty workaround function that a little bit difficult to be understood", I need to find a better and clean way to accomplish it.

I noticed there were some global Lisp_Object such as "f_Vface_font_rescale_alist"/"f_Vface_remapping_alist"/"f_Vface_new_frame_defaults", maybe I can use them, Hope so.
Thanks.



reply via email to

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