From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Bidi reordering engine upgraded Date: Thu, 16 Oct 2014 15:27:17 +0200 Message-ID: <8738ao5emi.fsf@zigzag.favinet> References: <834mv55quj.fsf@gnu.org> <543E9122.6070605@yandex.ru> <8338ap5o7l.fsf@gnu.org> <543E9A1C.2010904@yandex.ru> <831tq95m6x.fsf@gnu.org> <83zjcx450f.fsf@gnu.org> <83y4sh43zq.fsf@gnu.org> <543F41C9.3000507@yandex.ru> <83oatc4gz3.fsf@gnu.org> <877g005p11.fsf@zigzag.favinet> <83egu848xv.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1413465835 15439 80.91.229.3 (16 Oct 2014 13:23:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 13:23:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 16 15:23:49 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xel1r-0001c6-S6 for ged-emacs-devel@m.gmane.org; Thu, 16 Oct 2014 15:23:43 +0200 Original-Received: from localhost ([::1]:50438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xel1r-0002rj-FW for ged-emacs-devel@m.gmane.org; Thu, 16 Oct 2014 09:23:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xel1i-0002rd-UU for emacs-devel@gnu.org; Thu, 16 Oct 2014 09:23:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xel1d-0001Qc-KA for emacs-devel@gnu.org; Thu, 16 Oct 2014 09:23:34 -0400 Original-Received: from smtp209.alice.it ([82.57.200.105]:38686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xel1d-0001QN-9w for emacs-devel@gnu.org; Thu, 16 Oct 2014 09:23:29 -0400 Original-Received: from zigzag.favinet (95.249.52.234) by smtp209.alice.it (8.6.060.43) id 5433B0B701ADB694 for emacs-devel@gnu.org; Thu, 16 Oct 2014 15:23:27 +0200 Original-Received: from ttn by zigzag.favinet with local (Exim 4.80) (envelope-from ) id 1Xel5Y-0001jU-E6 for emacs-devel@gnu.org; Thu, 16 Oct 2014 15:27:32 +0200 Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: <83egu848xv.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Oct 2014 13:15:24 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.105 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175454 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () Eli Zaretskii () Thu, 16 Oct 2014 13:15:24 +0300 > The XDrawRectangle and XDrawRectangles functions draw the > outlines of the specified rectangle or rectangles as if a > five-point PolyLine protocol request were specified for > each rectangle: >=20 > [x,y] [x+width,y] [x+width,y+height] [x,y+height] [x,y] >=20 > So if you use the glyph width directly, the resulting rectangle > drawn will invade the next character cell by one pixel. The last sentence is your interpretation, because the documentation you cite does not explain what exactly it means by "the outlines of the rectangle". That is, it doesn't say whether the 1-pixel border of the outline exceeds the x+width coordinate, or ends at it. And that's the crucial point here. My interpretation is informed by the word "PolyLine" (and general experience playing w/ the X protocol[0], but that is tangential); i ignore the word "outline" as noise. XDrawline(3) explains things in gory detail, but to summarize, pixels "around" each point in a "polyline" are "rendered", so the upshot (of my example) is if =E2=80=98x= =E2=80=99 is 20, =E2=80=98w=E2=80=99 is 10, and the "line width" is 1, then the pixel at= 30,y will be rendered (undesirable) instead of the one at 29,y (desirable). > Probably (i don't have docs handy) the other toolkits' > rectangle-drawing primitives draw from X,Y to X+W-1,Y+H-1 I don't think so, at least not the w32 toolkit, whose documentation (http://msdn.microsoft.com/en-us/library/dd144838%28v=3Dvs.85%29.aspx) says: The FrameRect function draws a border around the specified rectangle by using the specified brush. The width and height of the border are always one logical unit. This is equivalent to what you cited from the X docs, AFAIU. I think it hinges on what how "the specified rectangle" is specified. Also, here the "around" does indeed cast ambiguity in my mind. ___________________________________________________ [0] that is, directly scheming on a socket (http://www.gnuvola.org/software/ttn-do/). See modules =E2=80=98(ttn-do zzz x-protocol)=E2=80=99 et al and program xout (xout.scm), proc =E2=80=98xout frame!=E2=80=99, specifically line 127 where the -1 occurs for the "manual XDrawRectangle", i.e., 4-segment (5 points) PolyLine protocol, call. =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) =3D> nil --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlQ/x7kACgkQZwMiJEyAdQJ8wwCgq1/BUcZnTUSTIeEPWQxUKsgu D24AoOU2fE3gZKal7BsfCo3Juv9M9Isq =ApPk -----END PGP SIGNATURE----- --=-=-=--