From unknown Tue Jun 17 03:36:28 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#71039 <71039@debbugs.gnu.org> To: bug#71039 <71039@debbugs.gnu.org> Subject: Status: :box :line-width and :underline :position should accept fractional sizes Reply-To: bug#71039 <71039@debbugs.gnu.org> Date: Tue, 17 Jun 2025 10:36:28 +0000 retitle 71039 :box :line-width and :underline :position should accept fract= ional sizes reassign 71039 emacs submitter 71039 JD Smith severity 71039 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 10:52:30 2024 Received: (at submit) by debbugs.gnu.org; 18 May 2024 14:52:30 +0000 Received: from localhost ([127.0.0.1]:33883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8LQD-0005Au-Sl for submit@debbugs.gnu.org; Sat, 18 May 2024 10:52:30 -0400 Received: from lists.gnu.org ([209.51.188.17]:55436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8LQC-0005Ao-LV for submit@debbugs.gnu.org; Sat, 18 May 2024 10:52:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8LQ8-0002ya-Sw for bug-gnu-emacs@gnu.org; Sat, 18 May 2024 10:52:24 -0400 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s8LQ3-0007gD-DZ for bug-gnu-emacs@gnu.org; Sat, 18 May 2024 10:52:23 -0400 Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-792b8bca915so144335985a.2 for ; Sat, 18 May 2024 07:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716043936; x=1716648736; darn=gnu.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=66cpJZWJ3bmtcEqgfRzvlMmRDLw/wfPh1bxg1eUZZGw=; b=XrrctiSYPN/pLYOAo+M99P7t0phj6uBhN9KO+I6yUg+uC+wcfvYR0tR+5eXXOFrAEX 3HnOBj86RASEYzN4mZll2Jyy2aQeQo2pMKeaa+7hxW2WTXwCkGk+jKiILWL3CcqV16h4 BeZet5XYuixLxcaNxjq7krZiBSedDFyBstyIcoPfJFK+s8NnYsLNJlsK+aox0s9n4Q2i vSkv2sJ/Jk0vE76wkfVISih98Px4M3gv989GqJGgMF6J8qWhwx1T89EIP8K6rzC9WhLm 6yHPUIk2YLYuVlmcRyc7h6jrkzNn71Sw13w3/mMaaunpGWTKUiyN57tdRJag1ecwhLbQ +btg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716043936; x=1716648736; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=66cpJZWJ3bmtcEqgfRzvlMmRDLw/wfPh1bxg1eUZZGw=; b=ZcsKHMs8fG6TPT20r9FfHsgy747TZRK1Co2HzWwR3TvDWoH66brW5BcXEPijWGBg1H Hb/ccbyXcAmz9vLVqWwJFjae6XJRG90Xf3u/EDcm5pd1jNlbHQf44IUUneEPC8wwkyDm UuucIpY/rkldYD4tI+UvW654t2+gWkKv3kM8UwIrewLG/hU30QDPlETq6Uh73fnIHJdS WVPDLAhMU2PCfPuBNAip6R5OUGQmKiQul0z8Wrr2eW0Z1VD9iQfsgXOBpNbVBn9hNW/8 Wp/8BmIFnRDr07m/l9yNn6K1pJkMfFQ4LuYqgRRIX2OipGZOB43qxdRXT7NBXgw6ZHGY Exyw== X-Gm-Message-State: AOJu0YzGYs6bSx6VUEuhqGpJkysqwRyxj8fHRAe63HZhmeRxGMNn4eXk HSuJM4ybQA7Rp0b3BYc5bd0eW8kPlOm/OTXGhj1uoBhmy2E+cIr+dDZi2Q== X-Google-Smtp-Source: AGHT+IEu/2zUbwTAItKmDLJ9q03eDFGNxjnSdUssO7e/Gzud7yu7PSonf49NfZmRjAZzdM11vGfO5g== X-Received: by 2002:ae9:e204:0:b0:790:9dee:5ee5 with SMTP id af79cd13be357-792c75786aamr2523808085a.2.1716043935459; Sat, 18 May 2024 07:52:15 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7931a60e966sm124842885a.39.2024.05.18.07.52.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2024 07:52:14 -0700 (PDT) From: JD Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_B27B2B2A-C9FD-4A35-A93D-B3F92660FE56" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: :box :line-width and :underline :position should accept fractional sizes Message-Id: <10D600A8-9175-47E7-92DA-B9725AE9D303@gmail.com> Date: Sat, 18 May 2024 10:52:03 -0400 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::730; envelope-from=jdtsmith@gmail.com; helo=mail-qk1-x730.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --Apple-Mail=_B27B2B2A-C9FD-4A35-A93D-B3F92660FE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For modes which layout mostly on fixed character-width grids, it is = convenient to preserve that layout even as the text-scale changes. Most = of the size related attributes associated with display and face = properties accommodate this style well, since they accept floating point = values which adapt to the underlying char size. These include face = height, display height and raise, specified space dimensions, etc. =20 There are, however, two face size attributes which are hard-coded in = pixels: :box :linewidth and :underline :position. It would be very = convenient if these also accepted fractional floating point values. = E.g. a face attribute of: :box (:line-width (0.5 . -0.25))=20 would indicate a box with half a char width outside padding left & = right, and one-quarter char height padding above and below. In addition, :box would be even more powerful, and obviate the use of = SVG styling in many situations, if :box :line-width optionally accepted = a list of four parameters for box dimensions, one for each side: :line-width (left right top bottom) naturally as either pixel or floating point fractions. --Apple-Mail=_B27B2B2A-C9FD-4A35-A93D-B3F92660FE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

For modes which layout mostly on = fixed character-width grids, it is convenient to preserve that layout = even as the text-scale changes.  Most of the size related = attributes associated with display and face properties accommodate this = style well, since they accept floating point values which adapt to the = underlying char size.  These include face height, display height = and raise, specified space dimensions, etc. =   

There are, however, two face size = attributes which are hard-coded in pixels: :box :linewidth and = :underline :position.  It would be very convenient if these also = accepted fractional floating point values.  E.g. a face attribute = of:

:box (:line-width (0.5 . = -0.25)) 

would indicate a box = with half a char width outside padding left & right, and one-quarter = char height padding above and below.

In = addition, :box would be even more powerful, and obviate the use of SVG = styling in many situations, if :box :line-width optionally accepted a = list of four parameters for box dimensions, one for each = side:

:line-width (left right top = bottom)

naturally as either pixel = or floating point fractions.

= --Apple-Mail=_B27B2B2A-C9FD-4A35-A93D-B3F92660FE56-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 12:06:44 2024 Received: (at 71039) by debbugs.gnu.org; 18 May 2024 16:06:44 +0000 Received: from localhost ([127.0.0.1]:34208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8Ma3-0006la-Re for submit@debbugs.gnu.org; Sat, 18 May 2024 12:06:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8Ma1-0006l5-LT for 71039@debbugs.gnu.org; Sat, 18 May 2024 12:06:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8MZs-0003qJ-GK; Sat, 18 May 2024 12:06:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QBTeLg4EdWJy/NiDudJMAtFLFY8hS/xDkpQFnFZnwts=; b=rdXGiz5/k2g9 89RTLf4j6DR8warOz4HqZhYJf7sXwKDECvv6GcQQMXVcyoJAnnSY7kgxX/DdHD/Sb1aSCzOAnzaun AzDV1w1qbmIOUNkdGgUfhImPLGJGUwOqW7NmA9ka6oiH6wry+02Brz3Uit7A+5y46NAim9mAa4CmH 7sHVni0SEIbqt28xykyj/OkkiY1UAk6SigoXP7nr7Fe4ozZhiB8nIB5fumZGeR5VQJEJ1RXZTWiA1 S2x+pdqj8xv9HF6fwxDDAk1/Pz591AplUkzCksu6DQzuvT68X+xSNZF0Hr8fwKryaBzYC4Y1Ddax0 p8ExOgS6ohB6CXYnvP3gXw==; Date: Sat, 18 May 2024 19:06:29 +0300 Message-Id: <86le47cdfe.fsf@gnu.org> From: Eli Zaretskii To: JD Smith In-Reply-To: <10D600A8-9175-47E7-92DA-B9725AE9D303@gmail.com> (message from JD Smith on Sat, 18 May 2024 10:52:03 -0400) Subject: Re: bug#71039: :box :line-width and :underline :position should accept fractional sizes References: <10D600A8-9175-47E7-92DA-B9725AE9D303@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71039 Cc: 71039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: JD Smith > Date: Sat, 18 May 2024 10:52:03 -0400 > > There are, however, two face size attributes which are hard-coded in pixels: :box :linewidth and :underline : > position. It would be very convenient if these also accepted fractional floating point values. E.g. a face > attribute of: > > :box (:line-width (0.5 . -0.25)) > > would indicate a box with half a char width outside padding left & right, and one-quarter char height padding > above and below. Are you sure this is a good idea? What would you like this to do when two adjacent runs of text are shown using different-size fonts (which AFAIU is the main use case for this feature)? We currently force the thickness and position of the underline to be identical for all the characters of a stretch of underlined text, even if they are displayed using different fonts, and we take those values from the first part of the underlined text's stretch. This is because having the underline break or show differently in the middle of an underlined text has ugly appearance. OTOH, calculating the thickness and position in pixels from the face font's dimensions is easy enough if your code needs that. Given these two facts, I'm not sure supporting float values here will be worth the effort. > In addition, :box would be even more powerful, and obviate the use of SVG styling in many situations, if :box : > line-width optionally accepted a list of four parameters for box dimensions, one for each side: > > :line-width (left right top bottom) > > naturally as either pixel or floating point fractions. How is this different from specifying the thickness and the position, as we have today? From debbugs-submit-bounces@debbugs.gnu.org Sat May 18 21:33:46 2024 Received: (at 71039) by debbugs.gnu.org; 19 May 2024 01:33:46 +0000 Received: from localhost ([127.0.0.1]:35671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8VQo-0005x3-8V for submit@debbugs.gnu.org; Sat, 18 May 2024 21:33:46 -0400 Received: from mail-qt1-f173.google.com ([209.85.160.173]:45189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8VQm-0005wx-Sb for 71039@debbugs.gnu.org; Sat, 18 May 2024 21:33:45 -0400 Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-43e2bca05e8so10643021cf.2 for <71039@debbugs.gnu.org>; Sat, 18 May 2024 18:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716082355; x=1716687155; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=M2lwrL4jvNEQJcC8AFyvalD4Lw6ZA4utGz5lSVB6XGQ=; b=Dsi7WV8BpE6T5aGwwLtuPH2xCcIrJWRzBMjXgx6BiYWzttvUiCLbDG9UBhXeqy90Qf BrQSzUGhSQzWfjD0HuP/4AP/EH39lWj2j2gKiWwvUe5bm2i/zL/VHDi+BMi3b8SZeY8P dRkNWkWGCWx8GJTqBNH2fAxAAnFoOB8pw22LT3vo1JRgkL8SfzdG3KKa6TuDk+griWvW eUzFMDLl875mujHFn61eYCC+XHKJl5Tiq8VgEQVoRG9U5ze0aRpFT7W+AF3jMmd8jjMy wHNECygZsOjNQP7FAqxiqX1kltzVkIFDeQelxehwEXzjJXsxAEx7FQKNjVyHpoC3c6Si WnzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716082355; x=1716687155; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M2lwrL4jvNEQJcC8AFyvalD4Lw6ZA4utGz5lSVB6XGQ=; b=Lmouw8kDa2rxMB5XhJVlmULED6RNUCAXtIbuymuBrrAfNrJXZeTGEI9cVxSN4OfkmT AkBnP04aG1yXOQ8pg3ek8nLIl1IyUzkzaVoAn+fa7TIYWro71IwAhsJX2t7DJRpZhLI8 JAysMEMZjm5FfgK17j6hrpmIOjhMX8yzsE8VCrbf79CjKqcUCE+WzthOnvWQhtUkby0C FTaMtIynl00wq3x7OgFXowYXaFUopsUBuduWHTZwtFfpzTqxk7Ym6qgzetuvBYKWSCn/ ZDYEEYXyeFi/RQlRIbblnicu6MYNWVlw8lVlH9eLhxzTNtzakn98csbUyWLpU2fi+NZB Bj9g== X-Gm-Message-State: AOJu0Yw+TcXqPufMBQVX6JT25lRANcrgelE1r9nYHgfoY7GpyBXdhZcc usMpMI3BQdyhVoq5cEmuJ9JmQD0WYxs8jZAP0qO+SqJX2vYikmJBqqLFEA== X-Google-Smtp-Source: AGHT+IGn1ba4fiuF1WEfi1eZToka4/Ub2oG81+l2bOW72kc3ePBm79UgGlqeM/1cBFS5z4CaFvn0/A== X-Received: by 2002:a05:622a:1111:b0:43d:fa8f:53c1 with SMTP id d75a77b69052e-43dfdbbb18amr289095211cf.64.1716082355356; Sat, 18 May 2024 18:32:35 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-43e16c5485fsm89730731cf.2.2024.05.18.18.32.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2024 18:32:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: bug#71039: :box :line-width and :underline :position should accept fractional sizes From: JD Smith In-Reply-To: <86le47cdfe.fsf@gnu.org> Date: Sat, 18 May 2024 21:32:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10D600A8-9175-47E7-92DA-B9725AE9D303@gmail.com> <86le47cdfe.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71039 Cc: 71039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On May 18, 2024, at 12:06=E2=80=AFPM, Eli Zaretskii = wrote: >=20 >> From: JD Smith >> Date: Sat, 18 May 2024 10:52:03 -0400 >>=20 >> There are, however, two face size attributes which are hard-coded in = pixels: :box :linewidth and :underline : >> position. It would be very convenient if these also accepted = fractional floating point values. E.g. a face >> attribute of: >>=20 >> :box (:line-width (0.5 . -0.25))=20 >>=20 >> would indicate a box with half a char width outside padding left & = right, and one-quarter char height padding >> above and below. >=20 > Are you sure this is a good idea? =20 Definitely! I've spent a good bit of time working around the absence of = this feature (and, while I found solutions, they were too convoluted to = be practical). > What would you like this to do when > two adjacent runs of text are shown using different-size fonts (which > AFAIU is the main use case for this feature)? =20 They'd have different height boxes, and that would be the desired = effect. Sort of the same idea as something like: (insert "\n" (propertize " Short " 'face '(:box (:line-width (0 . -4)) = :inverse-video t)) (propertize " BOX " 'face '(:box (:line-width (0 . -2)) = :inverse-video t)) (propertize " tall box " 'face '(:box (:line-width (1 . 1)))) "\n") except also adaptive to the text height. Normally of course you would = not do this for random text. Instead you'd apply targeted floating :box = widths to short stretches of text, like labels. > We currently force the > thickness and position of the underline to be identical for all the > characters of a stretch of underlined text, even if they are displayed > using different fonts, and we take those values from the first part of > the underlined text's stretch. This is because having the underline > break or show differently in the middle of an underlined text has ugly > appearance. I wan't aware of this behavior, but I do see the value in that special = rule for underlines. It's possible that pixel position indeed makes the = most sense for underline, given the face-merging behavior you describe. = I included it mostly for completeness. More important is :box. For various effects which cover short stretches = of text like label boxes, etc., the ability to have the box thickness = scale with char size would be very useful. Often these use = inverse-video, so that the "box" is in the background color. Many = packages reach for SVG images in this context, but with a little help, = many of those uses could be avoided. > OTOH, calculating the thickness and position in pixels from the face > font's dimensions is easy enough if your code needs that. Sure, but upon text-scaling, this calculation needs to be performed = again (probably in a temporary buffer, and across many faces). Then, = per-buffer face remaps must be applied and managed, etc. I've done = that, but it's a lot to juggle for a simple box. > Given these two facts, I'm not sure supporting float values here will > be worth the effort. I'm confident they'd be used quite a lot. Do you have a sense of how = difficult these improvements would be? Since you can already now apply = fractional specified space like (space :width (0.25 . width)), I was = hopeful the calculations would be close at hand. >> In addition, :box would be even more powerful, and obviate the use of = SVG styling in many situations, if :box : >> line-width optionally accepted a list of four parameters for box = dimensions, one for each side: >>=20 >> :line-width (left right top bottom) >>=20 >> naturally as either pixel or floating point fractions. >=20 > How is this different from specifying the thickness and the position, > as we have today? AFAIU there is no :position offset for :box? Right now, :box can = specify thickness as a fixed number of pixels outside (or inside, if = negative) the character(s), and in recent versions these widths can = differ vertically and horizontally. But boxes are always centered = horizontally on the boxed text and vertically on the line (including any = line-spacing). What the above proposal would do is allow you to specify the box width = separately on all 4 sides of the affected text: left, right, top, and = bottom. So for example: :line-width (4 0 -0.25 -0.1) would push the box 4 pixel to the left, and pull the box down from the = top more than up from the bottom. As a related idea, following your = suggestion, you could keep :line-width as-is and add a :box :position = attribute that shifts the box vertically (which would be the same except = symmetric left/right). =20 The floating point width is probably more important, but this would = enable some useful effects like simple text-based progress bars, etc.=20= From debbugs-submit-bounces@debbugs.gnu.org Sun May 19 02:37:35 2024 Received: (at 71039) by debbugs.gnu.org; 19 May 2024 06:37:36 +0000 Received: from localhost ([127.0.0.1]:35800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8aAp-00015C-BG for submit@debbugs.gnu.org; Sun, 19 May 2024 02:37:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8aAm-000155-BN for 71039@debbugs.gnu.org; Sun, 19 May 2024 02:37:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8aAc-00080L-Vi; Sun, 19 May 2024 02:37:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=A0gjR8ypkAhXMEvJxr8eOLjoc3YXuAY02GHx7k8X5zY=; b=qS2bz3Tufq9y O9N0RQmE2Dy7RtrGkMLkucViEWeZxbiwBAp5bg4He9tjDvG7f2gyaSo+d3hCIfc4f1QBymr48iWVk Oxf7y+NbN8nz2f25Uqeu1vj2ftgUndowesZ5NzcBtt30CrCyFdUJN+LMgkDMHICMn7xLW2jyhNBgs FuZM2uu+eniU5/HozN4xogcgFsox4QlyD7l3D55KhSPwCQ5QagyJY8fEY2SOf2XVuM8srrPE9n7Bp Zs0r7dTlKXfdWgiEevug8Q4cjzKo16+jYDkHYrTJHprtOICO+N7m05MNCPmAI0a4BLIwLiy/RzTFp o44QFuNaQUR7xirhYVhJcA==; Date: Sun, 19 May 2024 09:37:19 +0300 Message-Id: <86ttiub940.fsf@gnu.org> From: Eli Zaretskii To: JD Smith In-Reply-To: (message from JD Smith on Sat, 18 May 2024 21:32:23 -0400) Subject: Re: bug#71039: :box :line-width and :underline :position should accept fractional sizes References: <10D600A8-9175-47E7-92DA-B9725AE9D303@gmail.com> <86le47cdfe.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71039 Cc: 71039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: JD Smith > Date: Sat, 18 May 2024 21:32:23 -0400 > Cc: 71039@debbugs.gnu.org > > > Are you sure this is a good idea? > > Definitely! I've spent a good bit of time working around the absence of this feature (and, while I found solutions, they were too convoluted to be practical). > > > What would you like this to do when > > two adjacent runs of text are shown using different-size fonts (which > > AFAIU is the main use case for this feature)? > > They'd have different height boxes, and that would be the desired effect. Sort of the same idea as something like: > > (insert "\n" > (propertize " Short " 'face '(:box (:line-width (0 . -4)) :inverse-video t)) > (propertize " BOX " 'face '(:box (:line-width (0 . -2)) :inverse-video t)) > (propertize " tall box " 'face '(:box (:line-width (1 . 1)))) > "\n") > > except also adaptive to the text height. Normally of course you would not do this for random text. Instead you'd apply targeted floating :box widths to short stretches of text, like labels. I think it will look ugly, but I guess to each their own. Anyway, the line width is stored in the face structure when the face is realized, and kept there for when the box face needs to be drawn. If the values are relative, the drawing back-end will need to compute the corresponding absolute width values by accessing the font metrics (or is it the height of the screen line?) at draw time. And we will need to do that for all the back-ends we have. Patches welcome. > I'm confident they'd be used quite a lot. Do you have a sense of how difficult these improvements would be? Since you can already now apply fractional specified space like (space :width (0.25 . width)), I was hopeful the calculations would be close at hand. The space width is calculated in the back-end-independent part of the display code (xdisp.c), because it yields a stretch glyph of a certain width (which is later drawn on screen as a stretch of background color). By contrast, the box face is implemented in back-end code (*term.c), since it needs to draw lines using the display-specific APIs. So we cannot use the same code in these two cases. > What the above proposal would do is allow you to specify the box width separately on all 4 sides of the affected text: left, right, top, and bottom. So for example: > > :line-width (4 0 -0.25 -0.1) > > would push the box 4 pixel to the left, and pull the box down from the top more than up from the bottom. As a related idea, following your suggestion, you could keep :line-width as-is and add a :box :position attribute that shifts the box vertically (which would be the same except symmetric left/right). > > The floating point width is probably more important, but this would enable some useful effects like simple text-based progress bars, etc. This will need to extend the face structure to store 4 line thickness values, not 2 as we do today. From debbugs-submit-bounces@debbugs.gnu.org Sun May 19 09:47:17 2024 Received: (at 71039) by debbugs.gnu.org; 19 May 2024 13:47:17 +0000 Received: from localhost ([127.0.0.1]:36281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8gse-0001AJ-N8 for submit@debbugs.gnu.org; Sun, 19 May 2024 09:47:17 -0400 Received: from mail-oi1-f179.google.com ([209.85.167.179]:44229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8gsb-0001A2-J1 for 71039@debbugs.gnu.org; Sun, 19 May 2024 09:47:14 -0400 Received: by mail-oi1-f179.google.com with SMTP id 5614622812f47-3c99fcedac1so789244b6e.0 for <71039@debbugs.gnu.org>; Sun, 19 May 2024 06:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716126364; x=1716731164; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QLuTK943jSvpT/NfH8bU2vS/mxlATsSF5DT1tS65U8g=; b=DdxqGOf2gLXKbkD7DK2+A2+DnFQuk1X/Exf3IeJUcfpVUnHWemAnJHJcvufDQYXACS ikfhy3VZw9/AP5jpHmy8oh2k2Q8ttVaRpqFnsbWzJFkO5kcMpJ5zVfNdQwCTYFTMRlr7 S09xt3itD1MbWdgwQchc60UYd1Me/gIKpa3n8jZZvHvhFleXVE2C4HU24yhh2N4hybgG b+AKeiNVj1GEOLPSHdg/Ac4QJ6WcmXpfOPV4hNKsZxG8klw6qYogIvOu3oTlW8YNO29t 5ftGARl95JTRRLru+0jzS/BHnQuUg0sFBKVrVaHRZKoVGZpR8mqWzwEW/HzJAU7mnPJ8 U2xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716126364; x=1716731164; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QLuTK943jSvpT/NfH8bU2vS/mxlATsSF5DT1tS65U8g=; b=lRX/Ert4VuGgA+JbdsTVbYOJeUtJyivsxlrUD2ZIAemuPU4JP4P6A/Dj7gZYuon8DC FUkA1GzOECQlMH9+SEjDkFOVnHO5gm0KtTJZfw4r51pDC+xs/EamrzBluvkE+nGBX4a9 IdC42vnlGMHUySazlGzBNyBhCGhoEv8ia3/TFD8QZ82ZPJfn0XIi1NAFZxAX+LCbgtrD Dy9J57cd/541yIbGoShW1EZaT/AI1+KRp95KL82sRrd9jMsGrfVdLQJ4qeOWD6t+LmPB ARtIpy21KapwSQlIoyZyFk+LV+9eI/AowAcgz36bEzOvj53OcH0jrxeWxx8jxn4JkvfR zDHA== X-Gm-Message-State: AOJu0YwfgW4HKaZ84q/8po01Xb65IygE8HIT3qhsm27x9afTfwnDw2IE lJ5gjY7v7ZtFQxh4G2bAANAKMpMQk/O7MXBkmpqmeF78e/UEB7Wx X-Google-Smtp-Source: AGHT+IHsXcORk61K57xAIw4GR5WY0m1TuceP9s6BhmTV5etJ5gmFn2lduI9YI1XGDkQIpchLhZcInA== X-Received: by 2002:a05:6808:18a0:b0:3c7:50ac:c570 with SMTP id 5614622812f47-3c9970b99c4mr32199655b6e.44.1716126363696; Sun, 19 May 2024 06:46:03 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id af79cd13be357-792bf27591bsm1095958085a.16.2024.05.19.06.46.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 May 2024 06:46:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: bug#71039: :box :line-width and :underline :position should accept fractional sizes From: JD Smith In-Reply-To: <86ttiub940.fsf@gnu.org> Date: Sun, 19 May 2024 09:45:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13291126-C65F-46C6-A614-81AEEFCC9F73@gmail.com> References: <10D600A8-9175-47E7-92DA-B9725AE9D303@gmail.com> <86le47cdfe.fsf@gnu.org> <86ttiub940.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71039 Cc: 71039@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On May 19, 2024, at 2:37=E2=80=AFAM, Eli Zaretskii = wrote: >=20 >> Normally of course you would not do this for random text. Instead = you'd apply targeted floating :box widths to short stretches of text, = like labels. >=20 > I think it will look ugly, but I guess to each their own. That's just a random example, not meant for appearance evaluation ;). = It's already the idea used for popular packages like org-modern (with = some difficulty resulting from the limitations of :box). The basic idea = is to give more flexibility for box placement, which will open up many = uses. > Anyway, the line width is stored in the face structure when the face > is realized, and kept there for when the box face needs to be drawn. > If the values are relative, the drawing back-end will need to compute > the corresponding absolute width values by accessing the font metrics I guess this is how face must already handle :height, selecting a font = based on that (after inheritance, and multiplying all the :height's = together). Perhaps turning fractional box size into pixel values could = make use of that work? Surely that is not back-end dependent. > (or is it the height of the screen line?) at draw time. =20 Ideally the fractional box widths would be relative to the font size = itself, but I think line height would also be fine, if that were simpler = and more performant. >> I'm confident they'd be used quite a lot. Do you have a sense of how = difficult these improvements would be? Since you can already now apply = fractional specified space like (space :width (0.25 . width)), I was = hopeful the calculations would be close at hand. >=20 > The space width is calculated in the back-end-independent part of the > display code (xdisp.c), because it yields a stretch glyph of a certain > width (which is later drawn on screen as a stretch of background > color). By contrast, the box face is implemented in back-end code > (*term.c), since it needs to draw lines using the display-specific > APIs. So we cannot use the same code in these two cases. I see, thanks. Given that, it would probably be worthwhile to get = broader input on what types of back-end dependent screen drawing = improvements would be valuable for faces. >> What the above proposal would do is allow you to specify the box = width separately on all 4 sides of the affected text: left, right, top, = and bottom. So for example: >>=20 >> :line-width (4 0 -0.25 -0.1) >>=20 >> would push the box 4 pixel to the left, and pull the box down from = the top more than up from the bottom. As a related idea, following your = suggestion, you could keep :line-width as-is and add a :box :position = attribute that shifts the box vertically (which would be the same except = symmetric left/right). =20 >>=20 >> The floating point width is probably more important, but this would = enable some useful effects like simple text-based progress bars, etc. >=20 > This will need to extend the face structure to store 4 line thickness > values, not 2 as we do today. Or 3, if the :position flavor were deemed superior. =20 Thanks for the information.