From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from cgl.ntg.nl (Cgl.ntg.nl [5.39.185.202]) by inbox.vuxu.org (Postfix) with ESMTP id A10DB2886D for ; Tue, 13 Feb 2024 22:53:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by cgl.ntg.nl (Postfix) with ESMTP id 6E87E48439E for ; Tue, 13 Feb 2024 22:52:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cgl.ntg.nl Received: from cgl.ntg.nl ([127.0.0.1]) by localhost (cgl.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS_AXzKp2_uH for ; Tue, 13 Feb 2024 22:52:04 +0100 (CET) Received: from cgl.ntg.nl (localhost [127.0.0.1]) by cgl.ntg.nl (Postfix) with ESMTP id 48B7348445B for ; Tue, 13 Feb 2024 22:50:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by cgl.ntg.nl (Postfix) with ESMTP id 20D7B484279 for ; Tue, 13 Feb 2024 22:50:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cgl.ntg.nl Received: from cgl.ntg.nl ([127.0.0.1]) by localhost (cgl.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcZ-7uvzHUWi for ; Tue, 13 Feb 2024 22:50:05 +0100 (CET) Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cgl.ntg.nl (Postfix) with ESMTPS id CA769484276 for ; Tue, 13 Feb 2024 22:50:05 +0100 (CET) Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a3d2cce1126so52602166b.2 for ; Tue, 13 Feb 2024 13:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707861005; x=1708465805; darn=ntg.nl; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:from:to:cc:subject:date :message-id:reply-to; bh=X7UMtthgIUYxAzAtzDbAfaHJRUsunq9HBjb3GJqkIk0=; b=NlXszDGd+HaeCjxPeQJ16nz46nJXe6KsWaoay0fTe3h+LfxYvqBApQutUsGZgMg9rD JvaktBgr7lp8tvMJ0UHBu2nrbYq7yB/eEOhplyA1kVP4THJ7P7d61stqYGAU6Tps6Zvn oHfflPhq2GPJnoi/PYnhAuPLdoT64TZZmclumS1jfvleL6TsuJDjMRbJVFIPidoagaax eFtWqeQlVfsd2RFQ0LDOobIJ5vXwMz14HWzI/uLArGdKFwYc9k02jVqYiJ73dQIZ4yPf Nu6zBiY5jizUlVFVBIB9SChNEbCpymQJf3SL781/8Di2qg4I+7M13D0g1b3XXIy6LGA/ IAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707861005; x=1708465805; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=X7UMtthgIUYxAzAtzDbAfaHJRUsunq9HBjb3GJqkIk0=; b=JCGCytuC7Wps2FkwrTH0qSzxIaFfp20Tgpp4whn1mhAryaosB4h8Y1xduTE8LeDOYB J494XqWenjhHIACdYujigBuoXM5EApNVK6Ioxgd2rxy891GJtDRwHE4q60F5gYiflc93 ngBdB+SRJO3ngEml7N7APA8769CGDJcpSscnOR+Ws/X+uCMf8s2lbUlsgV1Rgy2/4gIe YtGhF8TDPfU8u69+ZGTsvbJu4IMyV28RW5Jv6mGCYBaT29yVkm52xGNEHoPkJaTVvkFu t89zQPRneGmT6i4S9nxh9AWO4YLzu6D3Dcf3ybXQLn4PeSPIp693DKzZNzL3MiYXqqV1 YR3A== X-Gm-Message-State: AOJu0YwEptOcmT6EP776S6dU7fpsKU4OMJ9hdAkWn4B4J6JBewrwD7h+ Ev1jNDfkcOdr85ymYdbkCCDNB/Z2Ts478H2VIIZqRptZGRc9t3KRJmXO38pG X-Google-Smtp-Source: AGHT+IEm3HqEkTnPXSgqzyQn+aNB+2EVEPIBxil09Khl4UuKec8leZcPx2rvrziXX5pibH6x7yXfEw== X-Received: by 2002:a17:907:1189:b0:a3c:aff2:b247 with SMTP id uz9-20020a170907118900b00a3caff2b247mr385188ejb.19.1707861005137; Tue, 13 Feb 2024 13:50:05 -0800 (PST) Received: from ?IPv6:2a02:810d:a8bf:dc10:81b7:fda8:628d:1a57? ([2a02:810d:a8bf:dc10:81b7:fda8:628d:1a57]) by smtp.gmail.com with ESMTPSA id vx1-20020a170907a78100b00a3d014fa12esm1008368ejc.196.2024.02.13.13.50.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2024 13:50:04 -0800 (PST) To: mailing list for ConTeXt users , SirColeman via ntg-context References: From: Wolfgang Schuster Message-ID: <99bfbcce-de93-005c-7060-b2caffd28179@gmail.com> Date: Tue, 13 Feb 2024 22:50:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.60 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Message-ID-Hash: WXRR2JQOJAKLPNHSFDZVU2PJX5AF57AS X-Message-ID-Hash: WXRR2JQOJAKLPNHSFDZVU2PJX5AF57AS X-MailFrom: wolfgang.schuster.lists@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: SirColeman X-Mailman-Version: 3.3.8 Precedence: list Reply-To: mailing list for ConTeXt users Subject: [NTG-context] Re: Two bugs with descriptions in ConTeXt. List-Id: mailing list for ConTeXt users Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: multipart/mixed; boundary="===============1371018373269089458==" This is a multi-part message in MIME format. --===============1371018373269089458== Content-Type: multipart/alternative; boundary="------------3C20E1F0F617854ACA572C93" Content-Language: en-US This is a multi-part message in MIME format. --------------3C20E1F0F617854ACA572C93 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit SirColeman via ntg-context schrieb am 13.02.2024 um 22:04: > The first bug is that descriptions interfere with the counters, > resulting in the peculiar behavior demonstrated in the resulting PDF. Still no bug and there is no need to create your own counter because enumerations exist which are descriptions with a counter. > Unless I'm mistaken, I think it happens because the head of the > description is evaluated twice, thus incrementing the counter > twice---at least, that's the only explanation for how the number is > incremented by 2 each time. Further, this issue seems to persist > whether we're using macros or writing \incrementcounter directly. > > The solution is to either make sure that the head of descriptions is > evaluated only once, or document that text placed as the head of > descriptions is meant to be evaluated twice, if there's a good reason > for doing so. Of course, this silly example of incrementing counters > can be subdued by placing the \incrementcounter directly in the after > option when customizing descriptions. But it demonstrates the issue. What you're supposed to do here is to increment the counter *before* you use the counter value. As you guessed the content of the title is evaluated multiple times to get the width of the description title, in cases where a counter is incremented in such a case (very common when you have counters in a table cell) you use the trialtypesetting mode to increment only once. > I've tried to make the examples given be as varied as possible, > demonstrating the different ways in which descriptions interact with > the counter. > > The second bug is that descriptions, or at least that's my intuitive > expectation, shouldn't interfere with the bullets of items. I expect > that the bullet stays where it is, and the description is placed next > to it. But what happens is that the bullet is shifted to the right, > making it overlap with the description's head, which isn't pretty. Is this even a real world example? The reason why the bullet points are at the wrong position is that descriptions and items use the same mechanism to set the text offset on the left and right sides and when you combine both mechanism the values are added. In case you you have a document where a descriptions appear as part of an item I suggest to use a different alternative (e.g. serried) for the description layout. Wolfgang --------------3C20E1F0F617854ACA572C93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit SirColeman via ntg-context schrieb am 13.02.2024 um 22:04:
The first bug is that descriptions interfere with the counters, resulting in the peculiar behavior demonstrated in the resulting PDF.

Still no bug and there is no need to create your own counter because enumerations exist which are descriptions with a counter.

Unless I'm mistaken, I think it happens because the head of the description is evaluated twice, thus incrementing the counter twice---at least, that's the only explanation for how the number is incremented by 2 each time. Further, this issue seems to persist whether we're using macros or writing \incrementcounter directly.

The solution is to either make sure that the head of descriptions is evaluated only once, or document that text placed as the head of descriptions is meant to be evaluated twice, if there's a good reason for doing so. Of course, this silly example of incrementing counters can be subdued by placing the \incrementcounter directly in the after option when customizing descriptions. But it demonstrates the issue.

What you're supposed to do here is to increment the counter *before* you use the counter value.

As you guessed the content of the title is evaluated multiple times to get the width of the description title, in cases where a counter is incremented in such a case (very common when you have counters in a table cell) you use the trialtypesetting mode to increment only once.

I've tried to make the examples given be as varied as possible, demonstrating the different ways in which descriptions interact with the counter.

The second bug is that descriptions, or at least that's my intuitive expectation, shouldn't interfere with the bullets of items. I expect that the bullet stays where it is, and the description is placed next to it. But what happens is that the bullet is shifted to the right, making it overlap with the description's head, which isn't pretty.

Is this even a real world example?

The reason why the bullet points are at the wrong position is that descriptions and items use the same mechanism to set the text offset on the left and right sides and when you combine both mechanism the values are added. In case you you have a document where a descriptions appear as part of an item I suggest to use a different alternative (e.g. serried) for the description layout.

Wolfgang

--------------3C20E1F0F617854ACA572C93-- --===============1371018373269089458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________ --===============1371018373269089458==--