From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23665 invoked from network); 17 May 2023 04:34:04 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 17 May 2023 04:34:04 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed May 17 00:31:58 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1684297976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VuZzLn0rBMjYDCIFYok0i5hPWWlua9Hjd1rYnZExptI=; b=ZRTOOULWA9Qt/UGCrQCOTmPAP+XM3yyU0L+v8vWpcHczoU3ssm0RuxhZmuG9VIrAdRqXSU zfWz9nURds9QPV2fO+5z+oGCk7vwMkdjMDHTr4jbYossHB8h/mn6+zWIJj6FouwdM8nc+Z unG96tmCuIDL14/2Uc2xhTGbffum40M= Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 72e60465 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Tue, 16 May 2023 23:32:53 -0500 (CDT) Message-ID: <238c17d3-d6b1-b12e-1c1a-39b1b658202b@posixcafe.org> Date: Tue, 16 May 2023 22:31:45 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-US To: 9front@9front.org References: From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: generic object-oriented markup Subject: Re: [9front] vnc: fix farsi key symbols Reply-To: 9front@9front.org Precedence: bulk On 5/16/23 20:38, unobe@cpan.org wrote: > Quoth Jacob Moody : >> I was told these were pulled from the openbsd keysymdef.h. >> I dont currently have an openbsd around but I believe this is the file, and these lines specifically: >> >> https://github.com/openbsd/xenocara/blob/d1a8d3ab034044bab40925e51534100a444dd3d6/proto/xorgproto/include/X11/keysymdef.h#L1011-L1100 >> >> It seems that they have elected to make the "new" unicode mapping the default, alongside the existing older keysyms in a similar way this >> patch does. Likewise the X11/keysym.h on my local loonix system has the same mapping. I agree that on paper the use of the new mappings >> for these codepoints specifically is a bit weird, but it seems to be consistently weird with "upstream". > > Thanks moody. Thank you for the first mail, the links had some good context to read through. There is likely some explanation for why these specific codepoints use the new format. If there is some consistent rule, maybe it could be refactored. > > In that case, more mappings like Arabic percent, the Arabic digits > (not Farsi) etc. could be updated to match. But that's for another > day. I also saw other codepoints that were defaulted to the new mapping when perusing the file. Perhaps a full sync is in order? Is there value in keeping these old tables around for old software? I am not too sure. > > As a side note which made me interested in this patch: I've only > recently started using more Arabic, but haven't used it via VNC, > mainly because the computer I'd VNC into has a much higher resolution > than my 9front display, so I only see a portion of the screen. I > don't see an easy way to scale the viewing window like some other VNC > viewers do. So being able to scale, or have the ability to view a > different part of the remote buffer, is a blocker. > It should be possible to create virtual 'headless' vnc servers of arbitrary resolutions. Maybe that will work in your case. I tend to go the other way with drawterm most of the time. thanks, moody