From MAILER-DAEMON Sun Nov 02 14:45:23 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xl15X-00086r-Ot for mharc-bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:45:23 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl15O-00081o-M0 for bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:45:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xl15H-0006ZP-7u for bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:45:14 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:55766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl15G-0006UB-VM for bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:45:07 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sA2JY4in021118 for ; Sun, 2 Nov 2014 20:34:08 +0100 Date: Sun, 2 Nov 2014 20:45:02 +0100 From: Patrice Dumas To: TexInfo Support Subject: Re: makeinfo bug Message-ID: <20141102194502.GA24326@free.fr> Mail-Followup-To: Patrice Dumas , TexInfo Support References: <20140825083757.GC2900@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5456872C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by saturne.centre-cired.fr id sA2JY4in021118 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 19:45:22 -0000 On Mon, Aug 25, 2014 at 08:33:53PM +0800, Mahlon Smith ( =E9=A9=AC=E4=BC=A6= ) wrote: > Hi Pat, > You are right that @section, @subsection and @subsubsection can be rese= rved > for the top level only. >=20 > However, @heading, @subheading and @subsubheading are explicitly define= d in > the documentation as: "You may use the '@heading' command anywhere you = wish > for a section-style heading that will not appear in the table of conten= ts." > This allows for a consistently-formatted heading line anywhere in the > document. The underlying symbols should be indented too now. Thanks! --=20 Pat From MAILER-DAEMON Sun Nov 02 14:46:18 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xl16Q-0008BC-Uo for mharc-bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:46:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl16I-00089w-LS for bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:46:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xl16B-0006hx-73 for bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:46:10 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:55769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl16A-0006hq-UW for bug-texinfo@gnu.org; Sun, 02 Nov 2014 14:46:03 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sA2JZ7iN021134 for ; Sun, 2 Nov 2014 20:35:07 +0100 Date: Sun, 2 Nov 2014 20:46:05 +0100 From: Patrice Dumas To: bug-texinfo@gnu.org Subject: Re: makeinfo --docbook and @sc Message-ID: <20141102194605.GB24326@free.fr> Mail-Followup-To: Patrice Dumas , bug-texinfo@gnu.org References: <201409111648.s8BGmEDb012824@skeeve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409111648.s8BGmEDb012824@skeeve.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5456876B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 19:46:18 -0000 On Thu, Sep 11, 2014 at 07:48:14PM +0300, Aharon Robbins wrote: > Hi. > > It seems that current makeinfo --docbook just strips off the markup > for @sc{...}. > > There doesn't seem to be docbook markup for small caps, so I would > suggest that it'd be better to upcase the contents of @sc{}. This is done now. Thanks for the report! -- Pat From MAILER-DAEMON Mon Nov 03 03:15:16 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XlCnE-0006YW-PM for mharc-bug-texinfo@gnu.org; Mon, 03 Nov 2014 03:15:16 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl8E7-0004vS-Fc for bug-texinfo@gnu.org; Sun, 02 Nov 2014 22:22:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xl8E0-00012F-4P for bug-texinfo@gnu.org; Sun, 02 Nov 2014 22:22:43 -0500 Received: from p3nlsmtpcp01-01.prod.phx3.secureserver.net ([184.168.200.138]:33689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl8Dz-000125-T2 for bug-texinfo@gnu.org; Sun, 02 Nov 2014 22:22:36 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-01.prod.phx3.secureserver.net with : CPANEL : id ArLd1p00U2RsmEA01rLdFc; Sun, 02 Nov 2014 20:20:37 -0700 Received: from [124.207.38.54] (port=58819 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xl8Dx-0002pa-MQ for bug-texinfo@gnu.org; Sun, 02 Nov 2014 20:22:33 -0700 Message-ID: <5456F4F2.3070509@softwaresam.us> Date: Mon, 03 Nov 2014 11:22:26 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: makeinfo bug 'quotation' command Content-Type: multipart/alternative; boundary="------------000908010409050707090201" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.138 X-Mailman-Approved-At: Mon, 03 Nov 2014 03:15:16 -0500 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 03:22:50 -0000 This is a multi-part message in MIME format. --------------000908010409050707090201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi All, I couldn't find a reference to this one in the archive, so: RE: @quotation block Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) Bug: Left margin is being indented, but right margin is not. Documentation says: “both the left and right margins are closer to the center of the page, so the whole of the quotation is indented;” Paste the following at the top-level of any node and have a look. Remember that your --fill-column setting may affect the output. @subheading The '@@quotation' Command Note a bug in makeinfo v:5.2 which fails to define the right margin of thequotation block. | - - - - - - - - - - - - - - - - - - - - NATURAL BREAK OCCURS HERE => | - - -| <= - - - - - - - - QUOTATION MARGINS SHOULD OCCUR HERE => | @quotation "Hab SoSlI' Quch!" Be careful when using this phrase since a challenge will surely follow - and you will very likely experience death by bat'telh. @author traditional @end quotation @quotation Klingon Insult "Hab SoSlI' Quch!" Be careful when using this phrase since a challenge will surely follow - and you will very likely experience death by bat'telh. @author traditional @end quotation Cheers! Mahlon Note the new email (website is running again): sam_texinfo@softwaresam.us PS: Thanks, Pat for the update to the @*heading commands. :) -- Software Sam - software and tools for GNU/Linux /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------000908010409050707090201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi All,

I couldn't find a reference to this one in the archive, so:

RE: @quotation block

Version: makeinfo 5.2 (built from source on Fedora 20 x86_64)

Bug: Left margin is being indented, but right margin is not.

Documentation says:

both the left and right margins are closer to the center of the page, so the whole of the quotation is indented;”


Paste the following at the top-level of any node and have a look.

Remember that your --fill-column setting may affect the output.


@subheading The '@@quotation' Command


Note a bug in makeinfo v:5.2 which fails to define the right margin of the
quotation block.


| - - - - - - - - - - - - - - - - - - - - NATURAL BREAK OCCURS HERE => |

- - -| <= - - - - - - - - QUOTATION MARGINS SHOULD OCCUR HERE => |

@quotation

"Hab SoSlI' Quch!" Be careful when using this phrase since a challenge will

surely follow - and you will very likely experience death by bat'telh.

@author traditional

@end quotation


@quotation Klingon Insult

"Hab SoSlI' Quch!" Be careful when using this phrase since a challenge will

surely follow - and you will very likely experience death by bat'telh.

@author traditional

@end quotation



Cheers!

Mahlon

Note the new email (website is running again): sam_texinfo@softwaresam.us

PS: Thanks, Pat for the update to the @*heading commands. :)





--

Software Sam - software and tools for GNU/Linux

The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------000908010409050707090201-- From MAILER-DAEMON Mon Nov 03 14:41:49 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XlNVd-0004LR-9V for mharc-bug-texinfo@gnu.org; Mon, 03 Nov 2014 14:41:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlNVU-0004I6-A1 for bug-texinfo@gnu.org; Mon, 03 Nov 2014 14:41:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlNVM-0003G3-K4 for bug-texinfo@gnu.org; Mon, 03 Nov 2014 14:41:40 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:57983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlNVM-0003Fu-Ae for bug-texinfo@gnu.org; Mon, 03 Nov 2014 14:41:32 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sA3JULGG014674; Mon, 3 Nov 2014 20:30:24 +0100 Date: Mon, 3 Nov 2014 20:41:28 +0100 From: Patrice Dumas To: Mahlon Subject: Re: makeinfo bug 'quotation' command Message-ID: <20141103194128.GB19314@free.fr> Mail-Followup-To: Patrice Dumas , Mahlon , bug-texinfo@gnu.org References: <5456F4F2.3070509@softwaresam.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5456F4F2.3070509@softwaresam.us> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5457D7CD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by saturne.centre-cired.fr id sA3JULGG014674 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:41:48 -0000 On Mon, Nov 03, 2014 at 11:22:26AM +0800, Mahlon wrote: > Hi All, >=20 > I couldn't find a reference to this one in the archive, so: >=20 > RE: @quotation block >=20 > Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) >=20 > Bug: Left margin is being indented, but right margin is not. >=20 > Documentation says: >=20 > =E2=80=9Cboth the left and right margins are closer to the center of th= e > page, so the whole of the quotation is indented;=E2=80=9D It is a known issue, it is even in the tp/TODO file. I vaguely remember stating that indeed it was an issue, at least to Karl. Since you complained it could push it up but don't hold your breath... --=20 Pat From MAILER-DAEMON Fri Nov 07 07:29:27 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XmifP-0003fc-DG for mharc-bug-texinfo@gnu.org; Fri, 07 Nov 2014 07:29:27 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmdel-0008MZ-Je for bug-texinfo@gnu.org; Fri, 07 Nov 2014 02:08:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xmdeb-0002Ub-PJ for bug-texinfo@gnu.org; Fri, 07 Nov 2014 02:08:27 -0500 Received: from nm20.bullet.mail.bf1.yahoo.com ([98.139.212.179]:38648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmdeb-0002UX-Ec for bug-texinfo@gnu.org; Fri, 07 Nov 2014 02:08:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1415344096; bh=IkNqD0clHfVToT8qFEV39b5yQoChvtwy+SSjjUTLNFw=; h=Date:From:To:Subject:From:Subject; b=hn0I6+jAkoNwkOztg+u0JyoPv7390gK3kedgA/NxZopvZyM0OWlTBCG9BesZvj/ycbmRIaFwgYxVlxp/WR6kOrwtmOrTLo9/qCS8R/wKCkhx7G37APxry6xUPj2KEdTGG0qJsmc0jqrjHUK4SnsQjzuxzuYGHkknRR8vzQbhBikdy4TYW3dXxD4ZEV3Je/bt+m1Iu+pec5gVhOfEYtJeyRw2MYE1s71Q+8H0grC3PbTXJ35RBMgGopaI9aPXkJ6Qtx3ZlwPNohEbse0hlbmiL18qLUbv1FnmbSfSPy7JWkDxjr5ptaHEXW6XkNs7bkpJAUnUaD3C5KqDhEtMi4ZqCw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=LOvP4lgNYQIx6hK4s1TcrOjTydSSuhChINgAoJQcMXzsJ5fkFYwj42diGQ5d5jCTq8kIDNmpvzrf/9rE+7CD1D28cgHJMI/BlnjkChPQsXxJUocwOT9J4uGL/0ZVz4IKfdDprGcEbIyoV1fkkcQFL00m+soSMsl1bzPiemSbA/maz+thwVvrt35TPjRHpGNk/GfV/BUzjmul+xfPdxChocmfO8/jFi08lWL4HCKqTD/v64S5dyCFyOsVq4cMzCIJAXV+yyD0n/39iYCSLVhmVxEB/vCB1vLORPT0ADuX7snLX280EDBKrcwXlPd6tU0JWSDTyBChpJVKpn7SeG+3IA==; Received: from [98.139.215.142] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2014 07:08:16 -0000 Received: from [98.139.213.8] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2014 07:08:16 -0000 Received: from [127.0.0.1] by smtp108.mail.bf1.yahoo.com with NNFMP; 07 Nov 2014 07:08:16 -0000 X-Yahoo-Newman-Id: 825907.81462.bm@smtp108.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FOWX3x0VM1l.QUz9YcWlbbmpRkLOHCxL5.jAS8pg15kmtYV ovuC3NOEalGipYLU6F.Jy7iu_ULUt82mmkbzboMDuKPYRXANKXw80wF_Vywd EmKj_fMJ5e6wk21wVaDvhYcI2TrBjAYYTuV9uKYw0WZnG9eee7AgurLZM8LC Sh7EiiPzhVo4iWi6PCBtQVKp6SHv6YRKIAfySBDyojhVbe1qs_c7TT5jcC3j GxTE4q9zN30Eek4HvtCMDTrMpqxJxqW.peMaCH9.uXA8_RcK9oh.59aSGs14 rSsWBDspFPy3izFqUTt9m4e4MENXb3Lqi7c6EJWA3Let_Dw7ng_GviKLwiCl eHyl3rB4486V8FToZBAowP79atpcDlNra58AzuQChDrQs7_uM2jVEptIXzbD l4u5AZosBVHpd4KEkktqm9s_2CqX5aG8DjXye27QShJPivbfTf1sBv6nWqOD MZiQMgi4FyhCe.B2xcabC4AHXIRnCc5qM7KHcyiYLEfHy1jSjjxW8HAIg749 5ZPcmG8b7MfA0H7_PWADCsewYm00- X-Yahoo-SMTP: merhD1KswBCOGgml8bVfL5NEUQ-- Message-ID: <545C6FDB.9060709@yahoo.com.au> Date: Fri, 07 Nov 2014 17:08:11 +1000 From: Jason Hood User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: Texinfo install-info bug Content-Type: multipart/mixed; boundary="------------070001000202060506090009" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 98.139.212.179 X-Mailman-Approved-At: Fri, 07 Nov 2014 07:29:26 -0500 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:08:34 -0000 This is a multi-part message in MIME format. --------------070001000202060506090009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Greetings. There's a bug in install-info preventing --maxwidth from working; attached is a patch to fix it (for the 5.2 release; apply with -p1). -- Jason. --------------070001000202060506090009 Content-Type: text/plain; charset=windows-1252; name="bug.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bug.txt" ZGlmZiAtdXJwIHRleGluZm8tNS4yL2luc3RhbGwtaW5mby9pbnN0YWxsLWluZm8uYyB0ZXhp bmZvLTUuMmovaW5zdGFsbC1pbmZvL2luc3RhbGwtaW5mby5jCi0tLSB0ZXhpbmZvLTUuMi9p bnN0YWxsLWluZm8vaW5zdGFsbC1pbmZvLmMJMjAxMy0wOC0xNiAwMjowNzowOSArMTAwMAor KysgdGV4aW5mby01LjJqL2luc3RhbGwtaW5mby9pbnN0YWxsLWluZm8uYwkyMDE0LTExLTA1 IDIzOjMwOjU1ICsxMDAwCkBAIC0xNjQ0LDggKzE2NDQsNyBAQCByZWZvcm1hdF9uZXdfZW50 cmllcyAoc3RydWN0IHNwZWNfZW50cnkKICAgICAgICAgICBhbGlnbiA9IGFsaWduX2NsaTsK ICAgICAgICAgfQogCi0gICAgICBpZiAobWF4d2lkdGhfY2xpID09IC0xKQotICAgICAgICBt YXh3aWR0aCA9IDc5OworICAgICAgbWF4d2lkdGggPSBtYXh3aWR0aF9jbGkgPT0gLTEgPyA3 OSA6IG1heHdpZHRoX2NsaTsKIAogICAgICAgZm9ybWF0X2VudHJ5IChuYW1lLCBuYW1lX2xl biwgZGVzYywgZGVzY19sZW4sIGNhbGlnbiwgYWxpZ24sIAogICAgICAgICAgICAgICAgICAg ICBtYXh3aWR0aCwgJmVudHJ5LT50ZXh0LCAmZW50cnktPnRleHRfbGVuKTsK --------------070001000202060506090009-- From MAILER-DAEMON Fri Nov 07 07:29:28 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XmifQ-0003h5-H4 for mharc-bug-texinfo@gnu.org; Fri, 07 Nov 2014 07:29:28 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmeOd-0002ii-4I for bug-texinfo@gnu.org; Fri, 07 Nov 2014 02:55:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmeOW-0001T3-3P for bug-texinfo@gnu.org; Fri, 07 Nov 2014 02:55:51 -0500 Received: from nm32-vm6.bullet.mail.bf1.yahoo.com ([72.30.239.142]:56775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmeOV-0001Sl-R4 for bug-texinfo@gnu.org; Fri, 07 Nov 2014 02:55:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1415346943; bh=gl7r1icMBWBldjzq6wHTm3jlZpM8yDx2c8UMr70Jado=; h=Date:From:To:Subject:From:Subject; b=Afm57KOUyhzS4+IXVg4ORtuPLLAJVFlhCmohOCvp3C+MrE/+ovDpCEF6y7vsAhEOT1DZE4OIwdUsSH5nawwBA0CoGbqexMSxaYqV0+bq9vbQzsytQG91TxvXw6ohbfCsgxVE6RXqhG69b/uQSkxi8e3RGEnm0E0Ny2xCmQY4iGBzppaYS1eyt26s4tIzygFP0c8BYlF+DX7zWC2mFcmPYDOGN8NGyMAA1hF0+qBiBJY2zmAbyJMGiD2U9z70aOj0+tuCY/BUoEbQz9H2EAkEr4gK60iYwew+GaLmj/VYEpIzcGhvj6Af4fHI8c0gXhgadyqvwx7dxAX1/GlIZ2Ic6g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=b97paNKfyIsWvpr5oUXEa8wq92iEtnVkQ8jaT74k4d13MHRM39Akxs/TBNh/w/lLqpAHkH2FNiB+ogTLFgcpBSDd6c92mRbOcxAWwxhluNzZibhNEhGvilSThpNoYwiJxcMla77plVdvV70BgqdLuIX2A4yq0W18OmNZp/CnI40N//oUjCL1eYPh+rWJdMvHT88D15FWsJNZO8EeZZJGf/nH0XB7wpMiwPYbPZwQO18umqScc21T6c7CJuZl71R9FJkt3iF/LDW86TL0zTjUvUJZy4SZxVtNpxj7q3oqp6sxSvowdLuFYVKjT4QhZ1Z8x2phcmjITp4jK+vVD5fqeQ==; Received: from [66.196.81.170] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2014 07:55:43 -0000 Received: from [98.139.211.194] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2014 07:55:43 -0000 Received: from [127.0.0.1] by smtp203.mail.bf1.yahoo.com with NNFMP; 07 Nov 2014 07:55:43 -0000 X-Yahoo-Newman-Id: 10886.66561.bm@smtp203.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sNw231EVM1ns8tLV_qa0oPjlvUj2LR_QBalGRy.Z.Q0IT.d CIYRmo0LOkm89a8AUxAGyo4Rsiha4tBWfL7eL1qNnCRW7M0oAyIzJ4eni9s2 A5F30qzp.mVYBHbl6YdoRJQGsiq69sF289.Q_OsrYxpOe5TM14yXDNJZJULB Gi1JiNrV_LpQTsvLv2enYt51Xxyr6ritFdp0KxTfmtYmJVm1w6iEgfay0AVT 7jjFLeee_ra69oTdZXIukTuwco3Bp_i4VuAcL1BwwT2S6pGASKAPVxUuntxU cx3yR9Jgdo2E3HgR94QaKMN9y6MhQuuDstkkGFOowEQca7X8YBfWrwb5lFFw YwD.TCabhvRNwlaTnV8720CP_jNfV_Xl9xTG5xDc82k4vlKGZRUyg6ymf9ac Z15JMhi2wTRXfqxeLXYCrxV_t2IaQ.GocsCXXxOVEA4VrtsxJIWFxu6VUqXv z_okZssuK1399Qz6okAx_bABnxvj_1Xo5EpQBCcf0TD_9mLgSbM_9u9NNP7e s7DKj8IfEXBKroiXeZq1Cr2zfAiE- X-Yahoo-SMTP: merhD1KswBCOGgml8bVfL5NEUQ-- Message-ID: <545C7AF8.9080102@yahoo.com.au> Date: Fri, 07 Nov 2014 17:55:36 +1000 From: Jason Hood User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: Texinfo Windows patch Content-Type: multipart/mixed; boundary="------------010709010401000806050508" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 72.30.239.142 X-Mailman-Approved-At: Fri, 07 Nov 2014 07:29:26 -0500 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:55:57 -0000 This is a multi-part message in MIME format. --------------010709010401000806050508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Greetings. Find attached a patch (based on the 5.2 release; apply with -p1) to address some issues with the Windows port: * enhances the gnulib stat replacement to provide meaningful values for st_ino & st_dev, thus enabling detection of duplicate directories; * improves the visual bell; * improves screen output (faster, correctly displays both UTF-8 and latin1 files). -- Jason. --------------010709010401000806050508 Content-Type: text/plain; charset=windows-1252; name="win.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="win.txt" ZGlmZiAtdXJwIHRleGluZm8tNS4yL2dudWxpYi9saWIvc3RhdC5jIHRleGluZm8tNS4yai9n bnVsaWIvbGliL3N0YXQuYwotLS0gdGV4aW5mby01LjIvZ251bGliL2xpYi9zdGF0LmMJMjAx My0wMi0yMCAwODoyNToyOSArMTAwMAorKysgdGV4aW5mby01LjJqL2dudWxpYi9saWIvc3Rh dC5jCTIwMTQtMTEtMDUgMjM6MzA6NTUgKzEwMDAKQEAgLTI4LDYgKzI4LDggQEAKICN1bmRl ZiBfX25lZWRfc3lzdGVtX3N5c19zdGF0X2gKIAogI2lmIChkZWZpbmVkIF9XSU4zMiB8fCBk ZWZpbmVkIF9fV0lOMzJfXykgJiYgISBkZWZpbmVkIF9fQ1lHV0lOX18KKyMgZGVmaW5lIFdJ TjMyX0xFQU5fQU5EX01FQU4KKyMgaW5jbHVkZSA8d2luZG93cy5oPgogIyBpZiBfR0xfV0lO RE9XU182NF9CSVRfU1RfU0laRQogIyAgdW5kZWYgc3RhdCAvKiBhdm9pZCB3YXJuaW5nIG9u IG1pbmd3NjQgd2l0aCBfRklMRV9PRkZTRVRfQklUUz02NCAqLwogIyAgZGVmaW5lIHN0YXQg X3N0YXRpNjQKQEAgLTEzNCw1ICsxMzYsMzIgQEAgcnBsX3N0YXQgKGNoYXIgY29uc3QgKm5h bWUsIHN0cnVjdCBzdGF0CiAgICAgICAgIH0KICAgICB9CiAjZW5kaWYgLyogUkVQTEFDRV9G VU5DX1NUQVRfRElSICovCisjaWZkZWYgV0lOMzJfTEVBTl9BTkRfTUVBTgorICBpZiAocmVz dWx0ID09IDApCisgICAgeworICAgICAgLyogVW5kZXIgV2luZG93cywgc3RfZGV2ICgzMiBi aXRzKSBpcyB0aGUgZHJpdmUgbnVtYmVyICYgc3RfaW5vICgxNiBiaXRzKQorICAgICAgICAg aXMgYWx3YXlzIDAuICBUaGUgaGFuZGxlIGZpbGUgaW5mb3JtYXRpb24gY29udGFpbnMgYSAz Mi1iaXQgdm9sdW1lCisgICAgICAgICBzZXJpYWwgbnVtYmVyIChpLmUuIGEgZGV2aWNlIGlk KSB3aXRoIGEgNjQtYml0IGZpbGUgaW5kZXggKHVuaXF1ZSBmaWxlCisgICAgICAgICBpZCku ICBTaW5jZSB0aGUgdHdvIHN0IHZhbHVlcyBhcmUgYWx3YXlzIHRlc3RlZCB0b2dldGhlciwg cHV0IHRoZQorICAgICAgICAgbG93ZXIgMTYgYml0cyBvZiB0aGUgc2VyaWFsIGludG8gc3Rf aW5vIGFuZCBjb21iaW5lIHRoZSBpbmRleCB2YWx1ZXMKKyAgICAgICAgIGludG8gc3RfZGV2 IChicmllZiB0ZXN0aW5nIHNob3dzIHRoZSBsb3cgd29yZCBvZiB0aGUgaGlnaCBpbmRleCBh bmQKKyAgICAgICAgIHRoZSBoaWdoIHRocmVlIGRpZ2l0cyBvZiB0aGUgbG93IGluZGV4IGFy ZSBsaWtlbHkgMCkuICAqLworICAgICAgQllfSEFORExFX0ZJTEVfSU5GT1JNQVRJT04gZmk7 CisgICAgICBIQU5ETEUgaCA9IENyZWF0ZUZpbGUgKG5hbWUsIDAsCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEZJTEVfU0hBUkVfUkVBRHxGSUxFX1NIQVJFX1dSSVRFfEZJTEVf U0hBUkVfREVMRVRFLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVUxMLCBPUEVO X0VYSVNUSU5HLCBGSUxFX0ZMQUdfQkFDS1VQX1NFTUFOVElDUywKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTlVMTCk7CisgICAgICBpZiAoaCAhPSBJTlZBTElEX0hBTkRMRV9W QUxVRSkKKyAgICAgICAgeworICAgICAgICAgIGlmIChHZXRGaWxlSW5mb3JtYXRpb25CeUhh bmRsZSAoaCwgJmZpKSkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgc3QtPnN0X2lu byA9IExPV09SRCAoZmkuZHdWb2x1bWVTZXJpYWxOdW1iZXIpOworICAgICAgICAgICAgICBz dC0+c3RfZGV2ID0gKEhJV09SRCAoZmkubkZpbGVJbmRleEhpZ2gpIDw8IDI0KQorICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAoZmkubkZpbGVJbmRleExvdyAmIDB4RkZGRkZGKTsK KyAgICAgICAgICAgIH0KKyAgICAgICAgICBDbG9zZUhhbmRsZSAoaCk7CisgICAgICAgIH0K KyAgICB9CisjZW5kaWYKICAgcmV0dXJuIHJlc3VsdDsKIH0KZGlmZiAtdXJwIHRleGluZm8t NS4yL2luZm8vcGN0ZXJtLmMgdGV4aW5mby01LjJqL2luZm8vcGN0ZXJtLmMKLS0tIHRleGlu Zm8tNS4yL2luZm8vcGN0ZXJtLmMJMjAxMy0wOC0yMyAwMzo1NDowNiArMTAwMAorKysgdGV4 aW5mby01LjJqL2luZm8vcGN0ZXJtLmMJMjAxNC0xMS0wNyAxMTo1NzozNSArMTAwMApAQCAt MzksNiArMzksNyBAQAogI2luY2x1ZGUgPGlvLmg+CiAjaW5jbHVkZSA8Y29uaW8uaD4KICNp bmNsdWRlIDxwcm9jZXNzLmg+CisjZGVmaW5lIFdJTjMyX0xFQU5fQU5EX01FQU4KICNpbmNs dWRlIDx3aW5kb3dzLmg+CiAKIHN0cnVjdCB0ZXh0X2luZm8gewpAQCAtMjQ5LDExICsyNTAs MjAgQEAgU2NyZWVuVmlzdWFsQmVsbCAodm9pZCkKICAgRFdPUkQgbmNoYXJzID0gc2NyZWVu d2lkdGggKiBzY3JlZW5oZWlnaHQ7CiAgIENPT1JEIHN0YXJ0X3BvczsKICAgRFdPUkQgd3Jp dHRlbjsKKyAgUFdPUkQgYXR0cjsKKyAgRFdPUkQgaTsKIAogICBzdGFydF9wb3MuWCA9IHN0 YXJ0X3Bvcy5ZID0gMDsKLSAgRmlsbENvbnNvbGVPdXRwdXRBdHRyaWJ1dGUgKGhzY3JlZW4s IGludl9hdHRyLCBuY2hhcnMsIHN0YXJ0X3BvcywgJndyaXR0ZW4pOwotICBTbGVlcCAoMjAp OwotICBGaWxsQ29uc29sZU91dHB1dEF0dHJpYnV0ZSAoaHNjcmVlbiwgbm9ybV9hdHRyLCBu Y2hhcnMsIHN0YXJ0X3BvcywgJndyaXR0ZW4pOworICBhdHRyID0geG1hbGxvYyAobmNoYXJz ICogc2l6ZW9mIChXT1JEKSk7CisgIFJlYWRDb25zb2xlT3V0cHV0QXR0cmlidXRlIChoc2Ny ZWVuLCBhdHRyLCBuY2hhcnMsIHN0YXJ0X3BvcywgJndyaXR0ZW4pOworICBmb3IgKGkgPSAw OyBpIDwgbmNoYXJzOyArK2kpCisgICAgYXR0cltpXSBePSBub3JtX2F0dHIgXiBpbnZfYXR0 cjsKKyAgV3JpdGVDb25zb2xlT3V0cHV0QXR0cmlidXRlIChoc2NyZWVuLCBhdHRyLCBuY2hh cnMsIHN0YXJ0X3BvcywgJndyaXR0ZW4pOworICBTbGVlcCAoNTApOworICBmb3IgKGkgPSAw OyBpIDwgbmNoYXJzOyArK2kpCisgICAgYXR0cltpXSBePSBub3JtX2F0dHIgXiBpbnZfYXR0 cjsKKyAgV3JpdGVDb25zb2xlT3V0cHV0QXR0cmlidXRlIChoc2NyZWVuLCBhdHRyLCBuY2hh cnMsIHN0YXJ0X3BvcywgJndyaXR0ZW4pOworICBmcmVlIChhdHRyKTsKIH0KIAogaW50CkBA IC02NzAsNyArNjgwLDIzIEBAIHBjX3B1dF90ZXh0IChzdHJpbmcpCiAgIGlmIChzcGVlY2hf ZnJpZW5kbHkpCiAgICAgZnB1dHMgKHN0cmluZywgc3Rkb3V0KTsKICAgZWxzZQorI2lmZGVm IF9XSU4zMgorICAgIHsKKyAgICAgIERXT1JEIGR1bW15OworICAgICAgV0NIQVIgd3NbMjU2 XTsKKyAgICAgIC8qIE5ld2VyIGZpbGVzIHVzZSBVVEYtOCwgb2xkZXIgTGF0aW4xIChwcm9i YWJseSkuICovCisgICAgICBpbnQgbGVuID0gTXVsdGlCeXRlVG9XaWRlQ2hhciAoQ1BfVVRG OCwgTUJfRVJSX0lOVkFMSURfQ0hBUlMsIHN0cmluZywgLTEsCisJCQkJICAgICB3cywgMjU2 KTsKKyAgICAgIGlmIChsZW4gPT0gMCkKKwlsZW4gPSBNdWx0aUJ5dGVUb1dpZGVDaGFyICgx MjUyLCAwLCBzdHJpbmcsIC0xLCB3cywgMjU2KTsKKyAgICAgIGlmIChsZW4gPT0gMCkKKwlX cml0ZUNvbnNvbGVBIChoc2NyZWVuLCBzdHJpbmcsIHN0cmxlbiAoc3RyaW5nKSwgJmR1bW15 LCBOVUxMKTsKKyAgICAgIGVsc2UKKwlXcml0ZUNvbnNvbGVXIChoc2NyZWVuLCB3cywgbGVu IC0gMSwgJmR1bW15LCBOVUxMKTsKKyAgICB9CisjZWxzZQogICAgIGNwdXRzIChzdHJpbmcp OworI2VuZGlmCiB9CiAKIC8qIFJpbmcgdGhlIHRlcm1pbmFsIGJlbGwuICBUaGUgYmVsbCBp cyBydW5nIHZpc2libHkgaWYgdGhlIHRlcm1pbmFsIGlzCkBAIC02OTksNyArNzI1LDcgQEAg cGNfd3JpdGVfY2hhcnMgKHN0cmluZywgbmNoYXJzKQogICBpZiAoc3BlZWNoX2ZyaWVuZGx5 KQogICAgIHByaW50ZiAoIiUuKnMiLG5jaGFycywgc3RyaW5nKTsKICAgZWxzZQotICAgIGNw cmludGYgKCIlLi4qcyIsbmNoYXJzLCBzdHJpbmcpOworICAgIGNwcmludGYgKCIlLipzIixu Y2hhcnMsIHN0cmluZyk7CiB9CiAKIC8qIFNjcm9sbCBhbiBhcmVhIG9mIHRoZSB0ZXJtaW5h bCBmcm9tIFNUQVJUIHRvIChhbmQgZXhjbHVkaW5nKSBFTkQsCg== --------------010709010401000806050508-- From MAILER-DAEMON Fri Nov 07 08:26:03 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XmjYB-0000Bp-Rm for mharc-bug-texinfo@gnu.org; Fri, 07 Nov 2014 08:26:03 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmjY4-0008VK-W4 for bug-texinfo@gnu.org; Fri, 07 Nov 2014 08:26:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmjXy-0008Lk-VV for bug-texinfo@gnu.org; Fri, 07 Nov 2014 08:25:56 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:60047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmjXy-0008LU-KU for bug-texinfo@gnu.org; Fri, 07 Nov 2014 08:25:50 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NEO00G007B25E00@mtaout29.012.net.il> for bug-texinfo@gnu.org; Fri, 07 Nov 2014 15:24:15 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEO00H777WFDA10@mtaout29.012.net.il>; Fri, 07 Nov 2014 15:24:15 +0200 (IST) Date: Fri, 07 Nov 2014 15:25:41 +0200 From: Eli Zaretskii Subject: Re: Texinfo Windows patch In-reply-to: <545C7AF8.9080102@yahoo.com.au> X-012-Sender: halo1@inter.net.il To: Jason Hood Message-id: <83k337rvl6.fsf@gnu.org> References: <545C7AF8.9080102@yahoo.com.au> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Eli Zaretskii List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 13:26:02 -0000 > Date: Fri, 07 Nov 2014 17:55:36 +1000 > From: Jason Hood > > Find attached a patch (based on the 5.2 release; apply with -p1) to > address some issues with the Windows port: Thanks. > * enhances the gnulib stat replacement to provide meaningful values for > st_ino & st_dev, thus enabling detection of duplicate directories; Patches for Gnulib functions should be sent to the Gnulib mailing list, bug-gnulib@gnu.org. Btw, is this change really worth the hassle? Not being able to detect duplicate directories means (AFAIK) they will be searched twice, which is slightly slower if the directory does not have the file we want. But OTOH, the CreateFile call also slows down the program, right? > * improves screen output (faster, correctly displays both UTF-8 and > latin1 files). But doesn't that require to use a specific font (Lucida Console, AFAIR) to be able to show the Unicode characters, such as quotes, frequently used by UTF-8 encoded Info files nowadays? Thanks again for working on this. From MAILER-DAEMON Fri Nov 07 18:07:19 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xmsch-0007WD-EI for mharc-bug-texinfo@gnu.org; Fri, 07 Nov 2014 18:07:19 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmscZ-0007U4-WC for bug-texinfo@gnu.org; Fri, 07 Nov 2014 18:07:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmscT-000396-TC for bug-texinfo@gnu.org; Fri, 07 Nov 2014 18:07:11 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:44013 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmscT-00038v-L5 for bug-texinfo@gnu.org; Fri, 07 Nov 2014 18:07:05 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sA7N75tf020266; Fri, 7 Nov 2014 16:07:05 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sA7N74P3020263; Fri, 7 Nov 2014 23:07:04 GMT Date: Fri, 7 Nov 2014 23:07:04 GMT Message-Id: <201411072307.sA7N74P3020263@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: jadoxa@yahoo.com.au Subject: Re: Texinfo install-info bug In-Reply-To: <545C6FDB.9060709@yahoo.com.au> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 23:07:18 -0000 - if (maxwidth_cli == -1) - maxwidth = 79; + maxwidth = maxwidth_cli == -1 ? 79 : maxwidth_cli; Thanks Jason. K From MAILER-DAEMON Sat Nov 08 20:03:09 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XnGuL-0004rV-0z for mharc-bug-texinfo@gnu.org; Sat, 08 Nov 2014 20:03:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnGuD-0004nu-HP for bug-texinfo@gnu.org; Sat, 08 Nov 2014 20:03:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnGtz-0005g7-Rp for bug-texinfo@gnu.org; Sat, 08 Nov 2014 20:03:01 -0500 Received: from nm40-vm6.bullet.mail.bf1.yahoo.com ([72.30.239.214]:39096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnGtz-0005fv-O8 for bug-texinfo@gnu.org; Sat, 08 Nov 2014 20:02:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1415494966; bh=IFU/9nhzHnmpX4XSrIbYQgsE3EZIRKQ4WM2LuPjmUUk=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=FJm0EVmWv51K6RuNWjyrykXXAXg8x3BLpwrWeU4pil1UPPdc96dmurrQGRwSU8QK2kjhlGXEmQo6l7uLHevV5UbsYZfyC5L0gbNpCe0aTJTi8vV4mGM/vsWDUrciCF9XWi+WjTGbNgbRgEdN08HE09FpGiOl1dfV8ztR1ZSEMzT9hiLBzw3PqXo9XUYYZMVCnAnKlx3XpqF6A61Te99j836Yd64ABlTYPN5d7JpEVicrrtuaxVpCKHCLSh0EkzQ6t9vh6YoW3+MQ2Jh21jiKqHi0yJMoNzzuDY/vKZS9PWjea9g3PhwuytCcgPYu0pZzCUXjpjqDVL/wd+Yx48a8yw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=Ggos9CE7URDElo/WBB9QfrHc+/xiJ1WgirJvdHtBUlaLTh/wmc+kLm5vHCKBcyp+EuVtw0d2d06KHrwUAACryKTj2W+jBLYdvsLZXrmR7AoyqO6z0y63W9LVoAc4v8trsLtiop1UAdnsaSoizvr9C26FhF+CQKlT1v3/rQpSF6rG/Vrs7WEF0yAtUW3q+WkOJJx8avijt5Jyr8viWajynizTQEHDI9RMN0Iw5xKy7neGVlcrkUj1+28hBjJvf1f+DZTSfP5du3+F1j2lXW5Zq6UTkZthoZHKh8Yrc6jwHTAXmQgIMEAoi3SrAxLWyhYSEEgErsugv7I6QLqAJFhS0A==; Received: from [98.139.212.149] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 09 Nov 2014 01:02:46 -0000 Received: from [98.139.211.198] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 09 Nov 2014 01:02:46 -0000 Received: from [127.0.0.1] by smtp207.mail.bf1.yahoo.com with NNFMP; 09 Nov 2014 01:02:14 -0000 X-Yahoo-Newman-Id: 932855.53997.bm@smtp207.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: H1XKajkVM1mW45d5yEPoRXYiQBFG.HkvTnyqGpzg3jx1p66 lkpfXOOyCDmkfEKgab9Rb8V.Hy9qF9GOhyIQWdCR1_xcBEkIrevLkfFQXiMQ E8kePOMjW6g_g1nmAz9cETdeo.QiRQweN13qV6IOQXT16rdwrCd0s8r1rb1U UyyA5aS3mbOBF6K_eX9SYnj10CL2Oo_Per.G.uH5k04U1tbWVKvbnNHV_ukO EgqfvwPQJI9mBcudXaU0pN6HZeZ_8gQZ4AsliXjh6qDDTREjzMYaJJk0gZfD E20iGuXOQgNi_S5qfuKBOx82x.FMDHYFHJsluc3PGxapvbbkrEeeKNi8fjFk FTxNReKhFLIq258t7B6CqjogdihgDxKRf80V51g5JXRaCmLCOWgt7_ssFJUF SKKhrx6HJkTtrQgRW4ZSexIV7H9PiYqoicHvf6m83a7ZKL5Lbk.rlSP03dGb H8rBINam7._171MP7ao5gwzgoiEr7j2D3O2P5O6BiCyEFF4.wvEsbNzg6HPT JzvKW2yFJpo.a_aVWis9gGgFfOMMqoTQ81W9WlF9VcqPAhUSuh2RL_g0obqr 6rbL8mX1bFf3vtarLgH_XR3fLdw-- X-Yahoo-SMTP: merhD1KswBCOGgml8bVfL5NEUQ-- Message-ID: <545EBD10.7070202@yahoo.com.au> Date: Sun, 09 Nov 2014 11:02:08 +1000 From: Jason Hood User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: [Bulk] Re: Texinfo Windows patch References: <545C7AF8.9080102@yahoo.com.au> <83k337rvl6.fsf@gnu.org> In-Reply-To: <83k337rvl6.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 72.30.239.214 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:03:07 -0000 On 7/11/2014 23:25, Eli Zaretskii wrote: > Patches for Gnulib functions should be sent to the Gnulib mailing > list, bug-gnulib@gnu.org. In that case, I'll send the additional patches of my grep port. > Btw, is this change really worth the hassle? Yes, since when I used your Windows port with my INFOPATH variable, it would duplicate the entries in a dir file. > But doesn't that require to use a specific font (Lucida Console, > AFAIR) to be able to show the Unicode characters, such as quotes, > frequently used by UTF-8 encoded Info files nowadays? If you use a TrueType font, characters not in the font will show as the default character (i.e. the box); if you use a raster font, Windows will translate as best it can (so curly quotes will become their ASCII equivalent), otherwise you get a question mark. Either way is better than the wrong characters (latin1 interpreted as OEM or the raw UTF-8 bytes). (BTW, anyone who likes raster 8x12 might like my TrueType conversion: http://terminalvector.adoxa.vze.com/ It does have curly quotes.) -- Jason. From MAILER-DAEMON Mon Nov 10 01:56:58 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XniuI-0002uz-Od for mharc-bug-texinfo@gnu.org; Mon, 10 Nov 2014 01:56:58 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XniuA-0002tR-A9 for bug-texinfo@gnu.org; Mon, 10 Nov 2014 01:56:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xniu3-0000BZ-CO for bug-texinfo@gnu.org; Mon, 10 Nov 2014 01:56:50 -0500 Received: from aibo.runbox.com ([91.220.196.211]:45212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xniu3-0000BE-5q for bug-texinfo@gnu.org; Mon, 10 Nov 2014 01:56:43 -0500 Received: from [10.9.9.207] (helo=mailfront03.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1Xniu1-0005nt-6y for bug-texinfo@gnu.org; Mon, 10 Nov 2014 07:56:41 +0100 Received: from 70-36-239-128.dsl.dynamic.fusionbroadband.com ([70.36.239.128] helo=toshie.bothner.com) by mailfront03.runbox.com with esmtpsa (uid:757155 ) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) id 1Xnitv-0007F1-05 for bug-texinfo@gnu.org; Mon, 10 Nov 2014 07:56:35 +0100 Message-ID: <5460619E.1070608@bothner.com> Date: Sun, 09 Nov 2014 22:56:30 -0800 From: Per Bothner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: patch: set id attribute for part in DocBook Content-Type: multipart/mixed; boundary="------------020808000101010501060300" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.220.196.211 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 06:56:56 -0000 This is a multi-part message in MIME format. --------------020808000101010501060300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It would be nice if the DocBook output generated for @part would include an id attribute. This is used for setting the filename in "chunked html" output in the standard DocBook XSLT scripts. The attacked patch is definitely broken (it fails on the example in the texinfo manual with an @* in the part name). However, it does do what I need it to do. It would be much appreciated if someone who knows what they're doing could clean it up and check it in. -- --Per Bothner per@bothner.com http://per.bothner.com/ --------------020808000101010501060300 Content-Type: text/x-patch; name="part-id.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="part-id.patch" Index: tp/Texinfo/Convert/DocBook.pm =================================================================== --- tp/Texinfo/Convert/DocBook.pm (revision 5920) +++ tp/Texinfo/Convert/DocBook.pm (working copy) @@ -640,6 +640,12 @@ if ($root->{'extra'} and $root->{'extra'}->{'associated_node'}) { $attribute .= " id=\"$root->{'extra'}->{'associated_node'}->{'extra'}->{'normalized'}\""; } + elsif ($root->{'cmdname'} eq 'part' && $root->{'args'} and $root->{'args'}->[0]) { + my ($arg, $end_line) + = $self->_convert_argument_and_end_line($root->{'args'}->[0]); + $arg = Texinfo::Convert::NodeNameNormalization::_unicode_to_protected($arg); + $attribute .= " id=\"$arg\""; + } $result .= "<$command${attribute}>\n"; if ($root->{'args'} and $root->{'args'}->[0]) { my ($arg, $end_line) --------------020808000101010501060300-- From MAILER-DAEMON Mon Nov 10 05:42:48 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XnmQq-0000jt-8a for mharc-bug-texinfo@gnu.org; Mon, 10 Nov 2014 05:42:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnmQh-0000jP-UT for bug-texinfo@gnu.org; Mon, 10 Nov 2014 05:42:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnmQb-0005jp-SZ for bug-texinfo@gnu.org; Mon, 10 Nov 2014 05:42:39 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:33786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnmQb-0005jb-Jd for bug-texinfo@gnu.org; Mon, 10 Nov 2014 05:42:33 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAAAejJk020077; Mon, 10 Nov 2014 11:41:12 +0100 Date: Mon, 10 Nov 2014 11:41:47 +0100 From: Patrice Dumas To: Per Bothner Subject: Re: patch: set id attribute for part in DocBook Message-ID: <20141110104147.GB18767@free.fr> Mail-Followup-To: Patrice Dumas , Per Bothner , bug-texinfo@gnu.org References: <5460619E.1070608@bothner.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5460619E.1070608@bothner.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5460962D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by saturne.centre-cired.fr id sAAAejJk020077 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:42:46 -0000 On Sun, Nov 09, 2014 at 10:56:30PM -0800, Per Bothner wrote: > It would be nice if the DocBook output generated for @part > would include an id attribute. This is used for setting the filename > in "chunked html" output in the standard DocBook XSLT scripts. >=20 > The attacked patch is definitely broken (it fails on the example > in the texinfo manual with an @* in the part name). However, it does d= o what I > need it to do. It would be much appreciated if someone who knows what t= hey're > doing could clean it up and check it in. Indeed, id are added when there are nodes associated with sectioning commands and @part is never associated with nodes. The id from nodes obeys very strict constraints, explained in the HTML part of the manual, for example, a "Th@'e" =E0. leads to a-_0022Th_00e9_0022-_00c3_00a0_002e Is it ok? It would be consistent with other generated id. It is possible to have id slightly more readable, for instance what is used for file names in html, like a-_0022The_0022-A-_002e Opinion? > --=20 > --Per Bothner > per@bothner.com http://per.bothner.com/ > Index: tp/Texinfo/Convert/DocBook.pm > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- tp/Texinfo/Convert/DocBook.pm (revision 5920) > +++ tp/Texinfo/Convert/DocBook.pm (working copy) > @@ -640,6 +640,12 @@ > if ($root->{'extra'} and $root->{'extra'}->{'associated_node= '}) { > $attribute .=3D " id=3D\"$root->{'extra'}->{'associated_no= de'}->{'extra'}->{'normalized'}\""; > } > + elsif ($root->{'cmdname'} eq 'part' && $root->{'args'} and $= root->{'args'}->[0]) { > + my ($arg, $end_line) > + =3D $self->_convert_argument_and_end_line($root->{'args'= }->[0]); > + $arg =3D Texinfo::Convert::NodeNameNormalization::_unicode= _to_protected($arg); > + $attribute .=3D " id=3D\"$arg\""; > + } > $result .=3D "<$command${attribute}>\n"; > if ($root->{'args'} and $root->{'args'}->[0]) { > my ($arg, $end_line) From MAILER-DAEMON Mon Nov 10 08:59:38 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XnpVK-0006n1-0F for mharc-bug-texinfo@gnu.org; Mon, 10 Nov 2014 08:59:38 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnn6x-0000eE-BZ for bug-texinfo@gnu.org; Mon, 10 Nov 2014 06:26:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xnn6p-0003VB-R3 for bug-texinfo@gnu.org; Mon, 10 Nov 2014 06:26:19 -0500 Received: from outbox.sics.se ([193.10.64.137]:48774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnn6p-0003V3-LA for bug-texinfo@gnu.org; Mon, 10 Nov 2014 06:26:11 -0500 Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id A59D866F for ; Mon, 10 Nov 2014 12:26:08 +0100 (CET) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sAABQ84s013827 for ; Mon, 10 Nov 2014 12:26:08 +0100 Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by letter.sics.se (Postfix) with ESMTPS id 6A9BC40118 for ; Mon, 10 Nov 2014 12:26:08 +0100 (CET) Received: from octopussy.sics.se (octopussy.sics.se [193.10.135.228]) by norm.sics.se (Postfix) with ESMTPSA id 4CAED350 for ; Mon, 10 Nov 2014 12:26:08 +0100 (CET) From: Per Mildner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: texi2dvi bug when $TEX et al. are absolute paths Date: Mon, 10 Nov 2014 12:26:08 +0100 Message-Id: To: bug-texinfo@gnu.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: ip=193.10.135.228; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09NdLq85N - 45c42c3003a8 - 20141110 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NdLq85N&m=45c42c3003a8&t=20141110&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NdLq85N&m=45c42c3003a8&t=20141110&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NdLq85N&m=45c42c3003a8&t=20141110&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 193.10.64.137 X-Mailman-Approved-At: Mon, 10 Nov 2014 08:59:36 -0500 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 11:26:26 -0000 The texi2dvi --help says (as of "texi2dvi 5704 2014-07-07 17:45:16Z = karl"): > The values of the BIBER, BIBTEX, DVIPDF, DVIPS, HEVEA, LATEX, = MAKEINDEX, > MAKEINFO, PDFLATEX, PDFTEX, SED, T4HT, TEX, TEX4HT, TEXINDEX, and = THUMBPDF_CMD > environment variables are used to run those commands, if they are set. But this is not true, at all. Setting TEX to the absolute path of the = tex executable will cause texi2dvi to fail. The reason for the failure is that the values of these environment = variables are passed to the "findprog" function which "Return true if = PROG is somewhere in PATH, else false.", i.e. it looks in $PATH _only_. This makes the environment variables completely useless, except in the = cases where the executables are on PATH but have non-default base name, = which seems like an unlikely scenario. Regards, Per Mildner Per.Mildner@sics.se Swedish Institute of Computer Science From MAILER-DAEMON Mon Nov 10 13:31:58 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xntks-0003q6-2O for mharc-bug-texinfo@gnu.org; Mon, 10 Nov 2014 13:31:58 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xntkk-0003je-GY for bug-texinfo@gnu.org; Mon, 10 Nov 2014 13:31:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xntkb-0004Sr-SL for bug-texinfo@gnu.org; Mon, 10 Nov 2014 13:31:50 -0500 Received: from aibo.runbox.com ([91.220.196.211]:55713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xntkb-0004Sd-MN for bug-texinfo@gnu.org; Mon, 10 Nov 2014 13:31:41 -0500 Received: from [10.9.9.206] (helo=mailfront02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1Xntka-0004hI-Co; Mon, 10 Nov 2014 19:31:40 +0100 Received: from 70-36-239-128.dsl.dynamic.fusionbroadband.com ([70.36.239.128] helo=toshie.bothner.com) by mailfront02.runbox.com with esmtpsa (uid:757155 ) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) id 1XntiQ-0005Gd-85; Mon, 10 Nov 2014 19:29:26 +0100 Message-ID: <54610401.6010506@bothner.com> Date: Mon, 10 Nov 2014 10:29:21 -0800 From: Per Bothner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Patrice Dumas , bug-texinfo@gnu.org Subject: Re: patch: set id attribute for part in DocBook References: <5460619E.1070608@bothner.com> <20141110104147.GB18767@free.fr> In-Reply-To: <20141110104147.GB18767@free.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.220.196.211 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 18:31:56 -0000 On 11/10/2014 02:41 AM, Patrice Dumas wrote: > Indeed, id are added when there are nodes associated with sectioning > commands and @part is never associated with nodes. > > The id from nodes obeys very strict constraints, explained in the HTML > part of the manual, for example, > > a "Th@'e" . > > leads to > a-_0022Th_00e9_0022-_00c3_00a0_002e > > Is it ok? It would be consistent with other generated id. It is > possible to have id slightly more readable, for instance what is used > for file names in html, like > > a-_0022The_0022-A-_002e > > Opinion? I think these are 3 different questions: (1) Should DocBook output contain id attributes for @part commands? IMO, yes. (2) Should those id attributes be "mangled" using the same algorithm that id attributes from nodes are? I don't know of any reason why not. (3) Should we be less restrictive in what we allow in id attributes? I think that would be reasonable - though it might break compatibility. It seems wrong to mangle perfectly-reasonable non-ascii letters. In principle the id attribute can be any valid XML Name. If we mangle '' we're both losing information and making the output uglier. If we want to restrict filenames, that should be done by the DocBook processor (or a transformation stage between makeinfo and DocBook). However, all valid XML Names are valid filenames on modern desktop and server systems, so such mangling is not needed. Likewise, web servers and browsers can transparently mangle and demangle non-ascii URLs, so we join the 21st century, and not deal with it. (Maybe I'm being overly optimistic ...) Possible exceptions: XML Names allow '.' and ':' - it might be reasonable to convert those to '_'. My conclusion: The goal should be to generate the simplest and most minimal mangling to produce a valid and human-readable XML Name. I'm a big believer in "clean URLs". GNU should aim for that. The same logic would apply to html and xml output, FWIW. -- --Per Bothner per@bothner.com http://per.bothner.com/ From MAILER-DAEMON Mon Nov 10 20:27:22 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xo0Es-0007rx-8h for mharc-bug-texinfo@gnu.org; Mon, 10 Nov 2014 20:27:22 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo0Em-0007rn-7n for bug-texinfo@gnu.org; Mon, 10 Nov 2014 20:27:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo0Eh-0002SZ-S7 for bug-texinfo@gnu.org; Mon, 10 Nov 2014 20:27:16 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:60614 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo0Eh-0002Rr-L7 for bug-texinfo@gnu.org; Mon, 10 Nov 2014 20:27:11 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAB1R6hq007028; Mon, 10 Nov 2014 18:27:06 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAB1R5n9007026; Tue, 11 Nov 2014 01:27:05 GMT Date: Tue, 11 Nov 2014 01:27:05 GMT Message-Id: <201411110127.sAB1R5n9007026@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: Per.Mildner@sics.se Subject: Re: texi2dvi bug when $TEX et al. are absolute paths In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 01:27:21 -0000 Setting TEX to the absolute path of the tex executable will cause texi2dvi to fail. Thanks for the report. Here's a patch, let me know if you see problems. I expect to commit it and push out a new texi2dvi to ftp.gnu.org tomorrow. Best, Karl --- texi2dvi (revision 5921) +++ texi2dvi (working copy) @@ -98,9 +98,6 @@ # Pacify verbose cds. CDPATH=${ZSH_VERSION+.}$path_sep -# If $TEX is set to a directory, don't use it. -test -n "$TEX" && test -d "$TEX" && unset TEX - # ## --------------------- ## ## Auxiliary functions. ## @@ -1733,9 +1730,15 @@ # We can't do much without tex. -# -if findprog ${TEX:-tex}; then :; else cat <&2 +You don't have a working TeX binary (tex) installed anywhere in your PATH, and texi2dvi cannot proceed without one. If you want to use this script, you'll need to install TeX (if you don't have it) or change your PATH or TEX environment variable (if you do). See the --help @@ -1744,20 +1747,19 @@ For information about obtaining TeX, please see http://tug.org/texlive, or do a web search for TeX and your operating system or distro. EOM - exit 1 -fi + exit 1 + fi - -# We want to use etex (or pdftex) if they are available, and the user -# didn't explicitly specify. We don't check for elatex and pdfelatex -# because (as of 2003), the LaTeX team has asked that new distributions -# use etex by default anyway. -# -# End up with the TEX and PDFTEX variables set to what we are going to use. -if test -z "$TEX"; then + # We want to use etex (or pdftex) if they are available, and the user + # didn't explicitly specify. We don't check for elatex and pdfelatex + # because (as of 2003), the LaTeX team has asked that new distributions + # use etex by default anyway. + # if findprog etex; then TEX=etex; else TEX=tex; fi fi -# + +# For many years, the pdftex binary has included the e-tex extensions, +# but just for those people with ancient TeX distributions ... if test -z "$PDFTEX"; then if findprog pdfetex; then PDFTEX=pdfetex; else PDFTEX=pdftex; fi fi From MAILER-DAEMON Tue Nov 11 04:32:06 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xo7ny-0006GY-1o for mharc-bug-texinfo@gnu.org; Tue, 11 Nov 2014 04:32:06 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo7np-0006FQ-3e for bug-texinfo@gnu.org; Tue, 11 Nov 2014 04:32:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo7nh-0004N0-Cm for bug-texinfo@gnu.org; Tue, 11 Nov 2014 04:31:57 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:49809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo7nh-0004Mq-1r for bug-texinfo@gnu.org; Tue, 11 Nov 2014 04:31:49 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAB9UZCX026156 for ; Tue, 11 Nov 2014 10:30:39 +0100 Date: Tue, 11 Nov 2014 10:31:41 +0100 From: Patrice Dumas To: bug-texinfo@gnu.org Subject: Re: patch: set id attribute for part in DocBook Message-ID: <20141111093141.GA3045@free.fr> Mail-Followup-To: Patrice Dumas , bug-texinfo@gnu.org References: <5460619E.1070608@bothner.com> <20141110104147.GB18767@free.fr> <54610401.6010506@bothner.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54610401.6010506@bothner.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5461D73B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by saturne.centre-cired.fr id sAB9UZCX026156 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:32:04 -0000 On Mon, Nov 10, 2014 at 10:29:21AM -0800, Per Bothner wrote: > I think these are 3 different questions: >=20 > (1) Should DocBook output contain id attributes for @part commands? >=20 > IMO, yes. Agreed. > (2) Should those id attributes be "mangled" using the same algorithm th= at > id attributes from nodes are? >=20 > I don't know of any reason why not. Filenames and section id are not mangled the same as nodes, since they cannot be target from other manuals, and sections need not be unique which imply that disambiguation is required anyway. If we add id for @part, I think I'll use the same as for sections. > (3) Should we be less restrictive in what we allow in id attributes? >=20 > I think that would be reasonable - though it might break compatibility. >=20 > It seems wrong to mangle perfectly-reasonable non-ascii letters. > In principle the id attribute can be any valid XML Name. If we mangle > '=E0' we're both losing information and making the output uglier. If w= e We do not lose information, the mangling scheme is a bijection with a unicode string. I don't think that there is code to demangle it, but we could in theory. With transliteration, for section id, even if not a bijection, -1 .. -n is prepended to make the id uniques, so there is no loss of information. > want to restrict filenames, that should be done by the DocBook processo= r > (or a transformation stage between makeinfo and DocBook). However, all > valid XML Names are valid filenames on modern desktop and server > systems, so such mangling is not needed. Likewise, web servers and > browsers can transparently mangle and demangle non-ascii URLs, > so we join the 21st century, and not deal with it. (Maybe I'm > being overly optimistic ...) That's not my philosophy. Especially for computer generated identifiers like those, backward compatibility is more important to me than having human readable identifier in urls. That being said, we could have different levels of compatibility/mangling. > Possible exceptions: XML Names allow '.' and ':' - it might be reasonab= le > to convert those to '_'. Not to _, to a unique value _XXXX, or something like that. > My conclusion: The goal should be to generate the simplest and most > minimal mangling to produce a valid and human-readable XML Name. For HTML, we use id/name for cross manual references. This must thus be independent of the document encoding as much as possible. Using ascii only seems to me the best bet in that regard (though not foolproof, there exist non ascii compatible encodings). Maybe instead of _XXXX we could use entities. The url could become more human readable this way when interpreted by a browser, but it will be even less human readable when reading with an editor. But if we do that, and change the url scheme, then we break all the cross-manual references, including to manuals that where generated a long time ago when the cross-manual specification was designed. As a side note, we already transliterate in file names, so we are not as certain for file name as we are for name/id that the result will be identical. Though it would be pretty rare to have something different, as we depend on a perl module that is quite stable and I am not aware of another translator to HTML that would not depend on that same perl module. > I'm a big believer in "clean URLs". GNU should aim for that. >=20 > The same logic would apply to html and xml output, FWIW. Currently, the id and name in HTML are designed to comply with XHTML 4.?? which is very restrictive. For XML output, we decide what is permitted in the dtd, but I think that it makes sense to use the mangled form which is also the internal representation of nodes. I searched a bit on the web, the restriction seems to be: ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). I don't remember why we didn't use ":" and ".", maybe simply me ignoring that we could, maybe compatibility with something older. In any case I don't think it would be that relevant to keep : and . as is while everything else is mangled. --=20 Pat From MAILER-DAEMON Fri Nov 14 06:43:53 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpFI9-00039I-1w for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 06:43:53 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpFI0-00038v-G2 for bug-texinfo@gnu.org; Fri, 14 Nov 2014 06:43:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpFHt-0003Ul-G4 for bug-texinfo@gnu.org; Fri, 14 Nov 2014 06:43:44 -0500 Received: from p3nlsmtpcp01-02.prod.phx3.secureserver.net ([184.168.200.140]:41794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpFHt-0003UM-8s for bug-texinfo@gnu.org; Fri, 14 Nov 2014 06:43:37 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-02.prod.phx3.secureserver.net with : CPANEL : id FPgn1p01D2RsmEA01PgnYM; Fri, 14 Nov 2014 04:40:47 -0700 Received: from [124.207.38.54] (port=48863 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XpFHq-0007aB-L1 for bug-texinfo@gnu.org; Fri, 14 Nov 2014 04:43:35 -0700 Message-ID: <5465EAE0.1040507@softwaresam.us> Date: Fri, 14 Nov 2014 19:43:28 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: makeinfo bug - smallquotation command Content-Type: multipart/alternative; boundary="------------030702090108070108080006" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.140 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 11:43:51 -0000 This is a multi-part message in MIME format. --------------030702090108070108080006 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 14 Nov. 2014 Sorry to be a pest, but I found a few more problems. I'll send them individually for ease in tracking. RE: '@smallquotation' command and its '@author' sub-command Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) Bug: The '@author', if specified within the '@smallquotation' block, is not displayed in the output. '@author' works as specified in the '@quotation' block, so the '@smallquotation' just needs to be made symmetrical. Sample Source: @smallquotation Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @author anon @end smallquotation Cheers! Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------030702090108070108080006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

14 Nov. 2014

Sorry to be a pest, but I found a few more problems.
I'll send them individually for ease in tracking.

RE: '@smallquotation' command and its '@author' sub-command

Version: makeinfo 5.2 (built from source on Fedora 20 x86_64)

Bug:

The '@author', if specified within the '@smallquotation' block,
is not displayed in the output.

'@author' works as specified in the '@quotation' block, so the '@smallquotation' just needs to be made symmetrical.

Sample Source:

@smallquotation

Heroes are seldom born. Instead, they spring to life when circumstances demand

it and recede into the background when the crisis has passed.

@author anon

@end smallquotation


Cheers!

Mahlon


--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------030702090108070108080006-- From MAILER-DAEMON Fri Nov 14 08:25:36 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpGsa-0007qZ-5a for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:25:36 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpGsX-0007qM-Hu for bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:25:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpGsV-0000mf-UR for bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:25:33 -0500 Received: from mail-ig0-x22b.google.com ([2607:f8b0:4001:c05::22b]:58292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpGsV-0000mZ-OM for bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:25:31 -0500 Received: by mail-ig0-f171.google.com with SMTP id uq10so210092igb.4 for ; Fri, 14 Nov 2014 05:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F7gbHVOUXwOJIIZvZAOjkUzta2x8LHbxRU9XaoSL0Zw=; b=ab1d6Hp0uD3jZyeuw37jybZI1bPiwLG9+4cCS2LFlrhohXuj5DsZMGSBMpKQIZlubP Yw4u3rM1Yic34gbSDTnTKjXSVe2SkAz+ZmDATqR2xh54JTz/sm/mcwOhupn/2ulmUzZm hEjOMqKkWn+OmVetnUwVPd1tma77r0uk3MOfFIV6lqO70Urud7hpGkWeeKgCO2LY3j24 9mIjIJTnbGop8skkoKKnGsK59H1H5L4pyIzKbNmY7ftsq59lwb6kdEUO3n1UfIf54tKx Jj5/+KVNcdoTaHokaZ+VH0fSC5Q/OAatxoIWQBkco0PvAwDJ1uhkpVUp0khwSrCjwihk TaTw== MIME-Version: 1.0 X-Received: by 10.50.221.33 with SMTP id qb1mr5892829igc.7.1415971530945; Fri, 14 Nov 2014 05:25:30 -0800 (PST) Received: by 10.107.170.150 with HTTP; Fri, 14 Nov 2014 05:25:30 -0800 (PST) In-Reply-To: <5465EAE0.1040507@softwaresam.us> References: <5465EAE0.1040507@softwaresam.us> Date: Fri, 14 Nov 2014 13:25:30 +0000 Message-ID: Subject: Re: makeinfo bug - smallquotation command From: Gavin Smith To: Mahlon Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::22b Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:25:34 -0000 I think the following fixes it. Could Patrice or Karl confirm? * tp/Texinfo/Convert/Plaintext.pm (_convert) <@quotation with @author>: Check if @smallquotation was used as well. Index: tp/Texinfo/Convert/Plaintext.pm =================================================================== --- tp/Texinfo/Convert/Plaintext.pm (revision 5923) +++ tp/Texinfo/Convert/Plaintext.pm (working copy) @@ -3142,7 +3142,9 @@ $result .= $self->_convert($tree); } } - } elsif ($root->{'cmdname'} eq 'quotation' and $root->{'extra'} + } elsif (($root->{'cmdname'} eq 'quotation' + or ($root->{'cmdname'} eq 'smallquotation')) + and $root->{'extra'} and $root->{'extra'}->{'authors'}) { foreach my $author (@{$root->{'extra'}->{'authors'}}) { $result .= $self->_convert( On Fri, Nov 14, 2014 at 11:43 AM, Mahlon wrote: > 14 Nov. 2014 > > Sorry to be a pest, but I found a few more problems. > I'll send them individually for ease in tracking. > > RE: '@smallquotation' command and its '@author' sub-command > > Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) > > Bug: > > The '@author', if specified within the '@smallquotation' block, > is not displayed in the output. > > '@author' works as specified in the '@quotation' block, so the > '@smallquotation' just needs to be made symmetrical. > > Sample Source: > > @smallquotation > > Heroes are seldom born. Instead, they spring to life when circumstances > demand > > it and recede into the background when the crisis has passed. > > @author anon > > @end smallquotation > > > Cheers! > > Mahlon > > > -- > > Software Sam - software and tools for GNU/Linux > > Mahlon Smith, > The Software Samurai > On the Web: http://www.SoftwareSam.us/ From MAILER-DAEMON Fri Nov 14 08:39:41 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpH6D-0004cD-Lp for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:39:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpH65-0004bV-1I for bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:39:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpH5x-0004qn-Uz for bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:39:32 -0500 Received: from p3nlsmtpcp01-03.prod.phx3.secureserver.net ([184.168.200.142]:46347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpH5x-0004qg-NZ for bug-texinfo@gnu.org; Fri, 14 Nov 2014 08:39:25 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-03.prod.phx3.secureserver.net with : CPANEL : id FRcv1p0182RsmEA01RcvYS; Fri, 14 Nov 2014 06:36:55 -0700 Received: from [124.207.38.54] (port=48992 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XpH5t-0000b3-AE for bug-texinfo@gnu.org; Fri, 14 Nov 2014 06:39:21 -0700 Message-ID: <54660602.5040301@softwaresam.us> Date: Fri, 14 Nov 2014 21:39:14 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: texinfo documentation? bug Content-Type: multipart/mixed; boundary="------------020003060904050302000107" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.142 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:39:40 -0000 This is a multi-part message in MIME format. --------------020003060904050302000107 Content-Type: multipart/alternative; boundary="------------090504000202070900050501" --------------090504000202070900050501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 14 Nov. 2014 RE: '@indent' and '@noindent' commands Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) Bug: The documentation is ambiguous at best, so my interpretation may not be the one intended by the author. /Note: This discussion assumes that the global @paragraphindent allows first-line indentation./ As I read it these commands are defined towork _outside_any block environment; however, the documentation says (indirectly) that these two commands should ALSO work inside environments _which __they do not_. Either the commands are broken inside environment blocks OR the documentation is wrong. Actually, I think _it is the documentation that is wrong._ Documentation: SeeChapter 10.14 'noindent': It shows an example where the @indent and @noindent are used inside a @display (actually a @verbatim)environment which is preformatted and therefore logically, should not be affected anyway. This example is ridiculously illogical (in my opinion) because it equates an @example block with first-line indentation. Of course the output for the examplehas no first-line indent because first-line indentation does not happen inside any environment block. For a more reasonable test, try pasting the attached intoan empty node. Cheers, Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------090504000202070900050501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

14 Nov. 2014

RE: '@indent' and '@noindent' commands

Version: makeinfo 5.2 (built from source on Fedora 20 x86_64)

Bug:

The documentation is ambiguous at best, so my interpretation may not be the one intended by the author. Note: This discussion assumes that the global @paragraphindent allows first-line indentation.

As I read it these commands are defined to work outside any block environment; however, the documentation says (indirectly) that these two commands should ALSO work inside environments which they do not. Either the commands are broken inside environment blocks OR the documentation is wrong.

Actually, I think it is the documentation that is wrong.

Documentation:

See Chapter 10.14 'noindent': It shows an example where the @indent and @noindent are used inside a @display (actually a @verbatim) environment which is preformatted and therefore logically, should not be affected anyway. This example is ridiculously illogical (in my opinion) because it equates an @example block with first-line indentation. Of course the output for the example has no first-line indent because first-line indentation does not happen inside any environment block.

For a more reasonable test, try pasting the attached into an empty node.

Cheers,

Mahlon



--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------090504000202070900050501-- --------------020003060904050302000107 Content-Type: text/x-texinfo; name="noindent_documentation_error.texi" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="noindent_documentation_error.texi" @subheading The '@@indent' and '@@noindent' Commands These are pairs of paragraphs representing each block type. The first paragraph of the pair is preceed by @@indent, and the second of the pair is preceeded by @@noindent. @noindent @code{1. outside any block} @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent @code{2. @@quotation block}@* @quotation @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @end quotation @noindent @code{3. @@indentedblock block}@* @indentedblock @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @end indentedblock @noindent @code{4. @@example block}@* @example @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @end example @noindent @code{5. @@display block}@* @display @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @end display @noindent @code{6. @@format block}@* @format @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @end format @noindent @code{7. @@verbatim block}@* @verbatim @indent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @noindent Heroes are seldom born. Instead, they spring to life when circumstances demand it and recede into the background when the crisis has passed. @end verbatim --------------020003060904050302000107-- From MAILER-DAEMON Fri Nov 14 16:54:50 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpOpO-0007hI-Ge for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 16:54:50 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpHxf-0007mU-SL for bug-texinfo@gnu.org; Fri, 14 Nov 2014 09:35:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpHxa-0004Ir-5j for bug-texinfo@gnu.org; Fri, 14 Nov 2014 09:34:55 -0500 Received: from mailout.assembly.state.ny.us ([204.97.104.4]:47844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpHxa-0004Ig-2Y for bug-texinfo@gnu.org; Fri, 14 Nov 2014 09:34:50 -0500 Received: from mail1.nysa.us (nysa-bh1.assembly.state.ny.us [204.97.104.30]) by mailout.assembly.state.ny.us (8.14.7/8.14.7) with ESMTP id sAEEYmmX032019 for ; Fri, 14 Nov 2014 09:34:48 -0500 Received: from ent1-10-2-10-154.nysa.us (dhcp-ent1st-10-2-10-154.nysa.us [10.2.10.154]) by mail1.nysa.us (8.14.2/8.14.2) with ESMTP id sAEEYlE1005389 for ; Fri, 14 Nov 2014 09:34:47 -0500 Message-ID: <54661307.2090609@fastmail.fm> Date: Fri, 14 Nov 2014 09:34:47 -0500 From: Zing Shishak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: 'h' should be 'H' in top node of info.info Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.2.10.4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 204.97.104.4 X-Mailman-Approved-At: Fri, 14 Nov 2014 16:54:48 -0500 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 14:35:01 -0000 In info version in fedora 20: info-5.1-4.fc20.x86_64, Running "info info" asks new users to: "If you are new to the Info reader and want to learn how to use it, type the command 'h' now. It brings you to a programmed instruction sequence." 'h' brings up a help list. It should prompt new users to hit 'H' which brings the user to the Help-Small-Screen node. From MAILER-DAEMON Fri Nov 14 17:09:57 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpP41-0003EG-Au for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:09:57 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpP3t-0003Bw-1n for bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:09:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpP3o-0001sN-CC for bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:09:48 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:38035 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpP3o-0001sH-5l for bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:09:44 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAEM9ejk010170; Fri, 14 Nov 2014 15:09:40 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAEM9cEM010160; Fri, 14 Nov 2014 22:09:38 GMT Date: Fri, 14 Nov 2014 22:09:38 GMT Message-Id: <201411142209.sAEM9cEM010160@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: zing@fastmail.fm Subject: Re: 'h' should be 'H' in top node of info.info In-Reply-To: <54661307.2090609@fastmail.fm> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:09:53 -0000 'h' brings up a help list. It should prompt new users to hit 'H' which brings the user to the Help-Small-Screen node. Thanks for the report. In the next release h in standalone Info will once again start the tutorial, same as Emacs Info. Best, Karl From MAILER-DAEMON Fri Nov 14 17:52:45 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpPjR-0000Jc-EJ for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:52:45 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpPjK-0000JI-4a for bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:52:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpPj9-000277-GJ for bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:52:38 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:40094 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpPj9-00026k-A7 for bug-texinfo@gnu.org; Fri, 14 Nov 2014 17:52:27 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAEMqPu2018742; Fri, 14 Nov 2014 15:52:25 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAEMqOaP018740; Fri, 14 Nov 2014 22:52:24 GMT Date: Fri, 14 Nov 2014 22:52:24 GMT Message-Id: <201411142252.sAEMqOaP018740@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: sam_texinfo@softwaresam.us Subject: Re: texinfo documentation? bug In-Reply-To: <54660602.5040301@softwaresam.us> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:52:44 -0000 Hi Mahlon, Thanks for the report, but ... The documentation is ambiguous at best Which is intentional, here and in plenty of other cases. I can't (don't want to) explicitly and completely define the result of every command in every context in the Texinfo manual. That's not its purpose. It shows an example where the @indent and @noindent are used inside a @display (actually a @verbatim) The purpose of that example is to show how to avoid indenting a paragraph following @example (one kind of generic "display"), which otherwise happens by default. That seems eminently practical to me, not nonsense. (The nesting inside @display...@end display may be odd, but it's conventional throughout the whole manual.) If there is a practical job you are trying to accomplish that the current code doesn't do, let us know. Otherwise, I don't see what needs to be changed. Best, Karl From MAILER-DAEMON Fri Nov 14 18:00:58 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpPrO-0001D9-Qu for mharc-bug-texinfo@gnu.org; Fri, 14 Nov 2014 18:00:58 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpPrH-0001D0-SX for bug-texinfo@gnu.org; Fri, 14 Nov 2014 18:00:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpPrB-0004aK-IW for bug-texinfo@gnu.org; Fri, 14 Nov 2014 18:00:51 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:54290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpPrB-0004a4-8b for bug-texinfo@gnu.org; Fri, 14 Nov 2014 18:00:45 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAEMwsOv002400; Fri, 14 Nov 2014 23:58:56 +0100 Date: Sat, 15 Nov 2014 00:00:31 +0100 From: Patrice Dumas To: Gavin Smith Subject: Re: makeinfo bug - smallquotation command Message-ID: <20141114230031.GA15786@free.fr> Mail-Followup-To: Patrice Dumas , Gavin Smith , Mahlon , Texinfo References: <5465EAE0.1040507@softwaresam.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5466892E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 23:00:58 -0000 On Fri, Nov 14, 2014 at 01:25:30PM +0000, Gavin Smith wrote: > I think the following fixes it. Could Patrice or Karl confirm? Indeed, it looks ok. I will check the tests and commit on your behalf if it is ok with you. > > * tp/Texinfo/Convert/Plaintext.pm (_convert) <@quotation with > @author>: Check if @smallquotation was used as well. > > Index: tp/Texinfo/Convert/Plaintext.pm > =================================================================== > --- tp/Texinfo/Convert/Plaintext.pm (revision 5923) > +++ tp/Texinfo/Convert/Plaintext.pm (working copy) > @@ -3142,7 +3142,9 @@ > $result .= $self->_convert($tree); > } > } > - } elsif ($root->{'cmdname'} eq 'quotation' and $root->{'extra'} > + } elsif (($root->{'cmdname'} eq 'quotation' > + or ($root->{'cmdname'} eq 'smallquotation')) > + and $root->{'extra'} > and $root->{'extra'}->{'authors'}) { > foreach my $author (@{$root->{'extra'}->{'authors'}}) { > $result .= $self->_convert( > > On Fri, Nov 14, 2014 at 11:43 AM, Mahlon wrote: > > 14 Nov. 2014 > > > > Sorry to be a pest, but I found a few more problems. > > I'll send them individually for ease in tracking. > > > > RE: '@smallquotation' command and its '@author' sub-command > > > > Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) > > > > Bug: > > > > The '@author', if specified within the '@smallquotation' block, > > is not displayed in the output. > > > > '@author' works as specified in the '@quotation' block, so the > > '@smallquotation' just needs to be made symmetrical. > > > > Sample Source: > > > > @smallquotation > > > > Heroes are seldom born. Instead, they spring to life when circumstances > > demand > > > > it and recede into the background when the crisis has passed. > > > > @author anon > > > > @end smallquotation > > > > > > Cheers! > > > > Mahlon > > > > > > -- > > > > Software Sam - software and tools for GNU/Linux > > > > Mahlon Smith, > > The Software Samurai > > On the Web: http://www.SoftwareSam.us/ > From MAILER-DAEMON Sat Nov 15 01:26:38 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpWog-0004Fo-MM for mharc-bug-texinfo@gnu.org; Sat, 15 Nov 2014 01:26:38 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpWoY-0004Fb-1E for bug-texinfo@gnu.org; Sat, 15 Nov 2014 01:26:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpWoQ-0007DY-SL for bug-texinfo@gnu.org; Sat, 15 Nov 2014 01:26:29 -0500 Received: from p3nlsmtpcp01-01.prod.phx3.secureserver.net ([184.168.200.138]:51569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpWoQ-0007DU-Ly for bug-texinfo@gnu.org; Sat, 15 Nov 2014 01:26:22 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-01.prod.phx3.secureserver.net with : CPANEL : id FiQF1p00l2RsmEA01iQFHv; Fri, 14 Nov 2014 23:24:15 -0700 Received: from [124.207.38.54] (port=33111 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XpWoM-0001VZ-Bk for bug-texinfo@gnu.org; Fri, 14 Nov 2014 23:26:18 -0700 Message-ID: <5466F204.60505@softwaresam.us> Date: Sat, 15 Nov 2014 14:26:12 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: HTML conversion should ignore 'exdent' command Content-Type: multipart/alternative; boundary="------------050106070909010106040604" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.138 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 06:26:37 -0000 This is a multi-part message in MIME format. --------------050106070909010106040604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 15 Nov 2014 RE: '@exdent' command in HTML output Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) Bug: The @exdent command is not very useful anywhere, but it is causing chaos in texi-to-HTML conversion. Logically, (and as documented) the HTML converter should ignore all instances of the @exdent command. Instead, it is being processed, but is not doing what is intended. TEXI SOURCE: @example unmodified line @exdent exdented line unmodified line @end example PRODUCES:
unmodified line

exdented line

unmodified line

The HTML itself is perfectly ok except that it produces double-spaced lines (each inside
 ... 
) and produces no 'exdented' line. Recommendation: All instances of @exdent, regardless of where they are encountered, should be ignored by the texi-to-HTML converter, and it should generate markup as if the @exdent weren't there—which for this example would be:
unmodified line

exdented line

unmodified line

Cheers, Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------050106070909010106040604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

15 Nov 2014

RE: '@exdent' command in HTML output

Version: makeinfo 5.2 (built from source on Fedora 20 x86_64)

Bug:

The @exdent command is not very useful anywhere, but it is causing chaos in texi-to-HTML conversion. Logically, (and as documented) the HTML converter should ignore all instances of the @exdent command. Instead, it is being processed, but is not doing what is intended.


TEXI SOURCE:

@example

unmodified line

@exdent exdented line

unmodified line

@end example


PRODUCES:

<div class="example">

<pre class="example">unmodified line

</pre><pre class="example">exdented line

</pre><pre class="example">unmodified line

</pre></div>


The HTML itself is perfectly ok except that it produces double-spaced lines (each inside <pre> ... </pre>) and produces no 'exdented' line.

Recommendation:

All instances of @exdent, regardless of where they are encountered, should be ignored by the texi-to-HTML converter, and it should generate markup as if the @exdent weren't there—which for this example would be:

<div class="example">

<pre class="example">unmodified line

exdented line

unmodified line

</pre></div>


Cheers,

Mahlon






--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------050106070909010106040604-- From MAILER-DAEMON Sat Nov 15 06:30:16 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XpbYW-0006Xi-P7 for mharc-bug-texinfo@gnu.org; Sat, 15 Nov 2014 06:30:16 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpbYO-0006S3-CV for bug-texinfo@gnu.org; Sat, 15 Nov 2014 06:30:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpbYG-0008KA-Ti for bug-texinfo@gnu.org; Sat, 15 Nov 2014 06:30:08 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:53958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpbYG-0008JT-Lx for bug-texinfo@gnu.org; Sat, 15 Nov 2014 06:30:00 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAFBS17v020055; Sat, 15 Nov 2014 12:28:16 +0100 Date: Sat, 15 Nov 2014 12:29:43 +0100 From: Patrice Dumas To: Mahlon Subject: Re: HTML conversion should ignore 'exdent' command Message-ID: <20141115112943.GA26753@free.fr> Mail-Followup-To: Patrice Dumas , Mahlon , bug-texinfo@gnu.org References: <5466F204.60505@softwaresam.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5466F204.60505@softwaresam.us> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 546738C1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 11:30:15 -0000 On Sat, Nov 15, 2014 at 02:26:12PM +0800, Mahlon wrote: > 15 Nov 2014 > > RE: '@exdent' command in HTML output > > Version: makeinfo 5.2 (built from source on Fedora 20 x86_64) > > Bug: > > The @exdent command is not very useful anywhere, but it is causing > chaos in texi-to-HTML conversion. Logically, (and as documented) the > HTML converter should ignore all instances of the @exdent command. > Instead, it is being processed, but is not doing what is intended. This issue can be approached from many sides. One is the Texinfo tree side. For now @exdent stops the paragraph or preformatted it is in, (same as what would do a block command such as @itemize, or other commands such as @center, @sp, @shortcontents or @verbatiminclude). It doesn't stop the @-command that started in the first place the preformatted environment, such as @example. This could be different, an @exdent could also be within the preformatted environment. The next side is trees transformation. We do that for HTML and Docbook to move index entries after items, such that @enumerate @cindex some index @item aa is transformed as @enumerate @item aa @cindex some index This would be an option, here, the issue is speed as the whole texinfo tree has to be run through. The last side is the translation to HTML. Maybe having a
 for the
@exdent line is not bad if it allows to exdent it for real.  I think
that it would be the best solution, even if it implies an extra line.  I
personnally do not know how to do that, but it could certainly be
doable.

Opinions, proposals?

-- 
Pat


From MAILER-DAEMON Sat Nov 15 18:49:12 2014
Received: from list by lists.gnu.org with archive (Exim 4.71)
	id 1Xpn5c-0005s8-Au
	for mharc-bug-texinfo@gnu.org; Sat, 15 Nov 2014 18:49:12 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53645)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1Xpn5T-0005q0-E7
	for bug-texinfo@gnu.org; Sat, 15 Nov 2014 18:49:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from ) id 1Xpn5N-0005u8-4w
	for bug-texinfo@gnu.org; Sat, 15 Nov 2014 18:49:03 -0500
Received: from frenzy.freefriends.org ([66.54.153.139]:59372
	helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1Xpn5M-0005te-UG
	for bug-texinfo@gnu.org; Sat, 15 Nov 2014 18:48:57 -0500
X-Envelope-From: karl@freefriends.org
Received: from freefriends.org (localhost [127.0.0.1])
	by freefriends.org (8.14.9/8.14.9) with ESMTP id sAFNmqaV021341;
	Sat, 15 Nov 2014 16:48:52 -0700
Received: (from nobody@localhost)
	by freefriends.org (8.14.9/8.14.9/submit) id sAFNmqOw021339;
	Sat, 15 Nov 2014 23:48:52 GMT
Date: Sat, 15 Nov 2014 23:48:52 GMT
Message-Id: <201411152348.sAFNmqOw021339@freefriends.org>
X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to
	karl@freefriends.org using -f
From: karl@freefriends.org (Karl Berry)
To: sam_texinfo@softwaresam.us, bug-texinfo@gnu.org
Subject: Re: HTML conversion should ignore 'exdent' command
In-Reply-To: <5466F204.60505@softwaresam.us>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-Received-From: 66.54.153.139
X-BeenThere: bug-texinfo@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Texinfo documentation system
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sat, 15 Nov 2014 23:49:09 -0000

Patrice,

1. Can CSS be used to accomplish the exdenting?  Extra blank lines seem
troublesome.  Ignoring @exdent doesn't sound right either.

2. In TeX, the exdented text is printed in roman.  I don't know if
HTML/CSS has a way to say "go back to the main font" (which might be
either serif or sans-serif in the HTML world) these days.  It didn't use
to.  Anyway, it would be nice if it could happen, but using either
span.roman or span.sansserif specifically doesn't seem right.

Best,
Karl


From MAILER-DAEMON Sun Nov 16 09:15:33 2014
Received: from list by lists.gnu.org with archive (Exim 4.71)
	id 1Xq0c1-0007pq-R3
	for mharc-bug-texinfo@gnu.org; Sun, 16 Nov 2014 09:15:33 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58165)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1Xq0bz-0007pk-KF
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 09:15:32 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from ) id 1Xq0by-0008TF-L2
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 09:15:31 -0500
Received: from mail-ie0-x233.google.com ([2607:f8b0:4001:c03::233]:59689)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1Xq0by-0008TB-GN
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 09:15:30 -0500
Received: by mail-ie0-f179.google.com with SMTP id rp18so404164iec.24
	for ; Sun, 16 Nov 2014 06:15:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=aCLt7VQAPtWED/PlEQU42vLgzAgpDsNTnN2+JLQOQCk=;
	b=yldziIvmlLg47rq1iSj2OZQeaK/xNCMOf7EaTDvPBc4ApdJuJnvoFK54D/nOSpe4/A
	WFvmjE5ex/E0irCbmD3SBZNQjWPQWQHyKVP+8YU5OK5h6XDoXfluFx6CZ0Nq/P5CyIKk
	DG3io5g35uFKDOiLsHvhWeI6lSOu8P06ciMa2NTDa+bjdykD5jR28/UAavtlKdZxHYzH
	RPlLU5OxKvPp8Y2ZAh0s99SEUP/NtHg/B3a38mFXK4pOG3LUJ3BZecT7qnhMyBfS6CI0
	syAbOXMmf4ni20J1+JR/g3LRnoVZFt7RZKqKTXzoWwNf/+d52FRlJP6BDq+XynmoEE5W
	lqiw==
MIME-Version: 1.0
X-Received: by 10.50.93.6 with SMTP id cq6mr19797680igb.7.1416147329743; Sun,
	16 Nov 2014 06:15:29 -0800 (PST)
Received: by 10.107.170.150 with HTTP; Sun, 16 Nov 2014 06:15:29 -0800 (PST)
In-Reply-To: <201411142252.sAEMqOaP018740@freefriends.org>
References: <54660602.5040301@softwaresam.us>
	<201411142252.sAEMqOaP018740@freefriends.org>
Date: Sun, 16 Nov 2014 14:15:29 +0000
Message-ID: 
Subject: Re: texinfo documentation? bug
From: Gavin Smith 
To: Karl Berry 
Content-Type: text/plain; charset=UTF-8
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
	(bad octet value).
X-Received-From: 2607:f8b0:4001:c03::233
Cc: Texinfo 
X-BeenThere: bug-texinfo@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Texinfo documentation system
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 16 Nov 2014 14:15:32 -0000

On Fri, Nov 14, 2014 at 10:52 PM, Karl Berry  wrote:
> Hi Mahlon,
>
> Thanks for the report, but ...
>
>     The documentation is ambiguous at best
>
> Which is intentional, here and in plenty of other cases.  I can't (don't
> want to) explicitly and completely define the result of every command in
> every context in the Texinfo manual.  That's not its purpose.
>
>     It shows an example where the @indent and
>     @noindent are used inside a @display (actually a @verbatim)
>
> The purpose of that example is to show how to avoid indenting a
> paragraph following @example (one kind of generic "display"), which
> otherwise happens by default.  That seems eminently practical to me, not
> nonsense.  (The nesting inside @display...@end display may be odd, but
> it's conventional throughout the whole manual.)
>

I think there is a problem that the manual could be read to imply that
@noindent is meaningful when used within a @display, when in fact it
does nothing: there would be no first-line indent even without
@noindent. It would probably be better to take out the aside about the
example being within a @display. I don't think first-line indentation
is desirable in any of the block environments in Mahlon's test file
(@quotation is documented as not having it, @indented block is said to
be like @quotation, and @example, @display and @format operate
line-by-line with no filling).


From MAILER-DAEMON Sun Nov 16 18:40:29 2014
Received: from list by lists.gnu.org with archive (Exim 4.71)
	id 1Xq9Qj-0005Iy-KS
	for mharc-bug-texinfo@gnu.org; Sun, 16 Nov 2014 18:40:29 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55534)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1Xq9Qb-0005Hr-9K
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 18:40:27 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from ) id 1Xq9QV-0002tr-0w
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 18:40:21 -0500
Received: from frenzy.freefriends.org ([66.54.153.139]:45003
	helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1Xq9QU-0002ti-Qq
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 18:40:14 -0500
X-Envelope-From: karl@freefriends.org
X-Envelope-To: 
Received: from freefriends.org (localhost [127.0.0.1])
	by freefriends.org (8.14.9/8.14.9) with ESMTP id sAGNeD9t017159
	for ; Sun, 16 Nov 2014 16:40:13 -0700
Received: (from nobody@localhost)
	by freefriends.org (8.14.9/8.14.9/submit) id sAGNeCjL017157;
	Sun, 16 Nov 2014 23:40:12 GMT
Date: Sun, 16 Nov 2014 23:40:12 GMT
Message-Id: <201411162340.sAGNeCjL017157@freefriends.org>
X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to
	karl@freefriends.org using -f
From: karl@freefriends.org (Karl Berry)
To: bug-texinfo@gnu.org
Subject: Re: texinfo documentation? bug
In-Reply-To: 
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-Received-From: 66.54.153.139
X-BeenThere: bug-texinfo@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Texinfo documentation system
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Sun, 16 Nov 2014 23:40:27 -0000

Hi Gavin,

    It would probably be better to take out the aside about the
    example being within a @display.

I know it seems weird, but otherwise there is no explanation for the
example as a whole being indented.  I don't remember, but I may have
added the aside precisely because someone wondered about that (or maybe
it was there all along, I dunno).  Anyway, I don't see a good way to
write the example without it, because the whole point is to show how to
not-indent a first line after an @example and the example as a whole
wouldn't come out right without being set off somehow.  I suppose I
could add ", thus this example's indentation as a whole" to the aside
but I suspect that would just make things worse.  Do you see a good
revision to make?

    (@quotation is documented as not having it, @indented block is said to
    be like @quotation, and @example, @display and @format operate
    line-by-line with no filling).

I agree, no first-line indentation there.  Is there a bug related to
this, in either the code or the manual?

thanks,
karl


From MAILER-DAEMON Sun Nov 16 22:42:32 2014
Received: from list by lists.gnu.org with archive (Exim 4.71)
	id 1XqDCy-0003pR-Px
	for mharc-bug-texinfo@gnu.org; Sun, 16 Nov 2014 22:42:32 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53319)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1XqDCp-0003pL-Va
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 22:42:31 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from ) id 1XqDCi-0008E9-Si
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 22:42:23 -0500
Received: from p3nlsmtpcp01-02.prod.phx3.secureserver.net
	([184.168.200.140]:48321) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from ) id 1XqDCi-0008E5-Ku
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 22:42:16 -0500
Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112])
	by p3nlsmtpcp01-02.prod.phx3.secureserver.net with : CPANEL :
	id GTfM1p00l2RsmEA01TfMC6; Sun, 16 Nov 2014 20:39:24 -0700
Received: from [124.207.38.54] (port=36443 helo=[192.168.0.103])
	by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa
	(TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84)
	(envelope-from ) id 1XqDCd-0006cA-AF
	for bug-texinfo@gnu.org; Sun, 16 Nov 2014 20:42:11 -0700
Message-ID: <54696E8C.1030403@softwaresam.us>
Date: Mon, 17 Nov 2014 11:42:04 +0800
From: Mahlon 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: bug-texinfo@gnu.org
Subject: 'raggedright' command in HTML output
Content-Type: multipart/alternative;
	boundary="------------080005000001090207070809"
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net
X-AntiAbuse: Original Domain - gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - softwaresam.us
X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id:
	sam_texinfo@softwaresam.us
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-Received-From: 184.168.200.140
X-BeenThere: bug-texinfo@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Texinfo documentation system
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-List-Received-Date: Mon, 17 Nov 2014 03:42:31 -0000

This is a multi-part message in MIME format.
--------------080005000001090207070809
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

17 Nov 2014

RE: @raggedright command

VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

BUG:

According to the documentation, the @raggedright command _does not apply 
to info and HTML output,_obviously because the command applies only to 
output formats that can produce 'justified' text. The 'info' output 
correctly processes the paragraph as ordinary paragraph text. Note 
however, that for some reason, _the HTML converter produces no output 
for the paragraph_. Below is my test:


@subheading The '@@raggedright' Command

This command applies only to output formats that can 'justify' 
i.e.spread text to fill the line. Text is left-justified (indented 
ifspecified), but leaving the right margin ragged.

@@raggedright @emph{does not} apply to 'info' and HTML output,

where text should be written as ordinary paragraph text.

@quotation

PLEASE NOTE: The paragraph below is not present at all in the HTML output.

@end quotation

@w{- - - MISSING HTML PARAGRAPH - - -}@*

@raggedright

When I left home for the first time, I took with me all the treasures of a

magical youth: three toy soldiers, a bag of cat's-eye marbles, my dad's 
Scout

knife, a clean handkerchief, $3.73 and my teddybear, Beathan.

@end raggedright

@w{- - - MISSING HTML PARAGRAPH - - -}

@sp 2



Cheers,

Mahlon





-- 

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
/The Software Samurai/
On the Web: /http://www.SoftwareSam.us/ 
/


--------------080005000001090207070809
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    

17 Nov 2014

RE: @raggedright command

VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

BUG:

According to the documentation, the @raggedright command does not apply to info and HTML output, obviously because the command applies only to output formats that can produce 'justified' text. The 'info' output correctly processes the paragraph as ordinary paragraph text. Note however, that for some reason, the HTML converter produces no output for the paragraph. Below is my test:


@subheading The '@@raggedright' Command

This command applies only to output formats that can 'justify' i.e. spread text to fill the line. Text is left-justified (indented if specified), but leaving the right margin ragged.

@@raggedright @emph{does not} apply to 'info' and HTML output,

where text should be written as ordinary paragraph text.

@quotation

PLEASE NOTE: The paragraph below is not present at all in the HTML output.

@end quotation

@w{- - - MISSING HTML PARAGRAPH - - -}@*

@raggedright

When I left home for the first time, I took with me all the treasures of a

magical youth: three toy soldiers, a bag of cat's-eye marbles, my dad's Scout

knife, a clean handkerchief, $3.73 and my teddybear, Beathan.

@end raggedright

@w{- - - MISSING HTML PARAGRAPH - - -}

@sp 2



Cheers,

Mahlon





--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------080005000001090207070809-- From MAILER-DAEMON Mon Nov 17 18:48:05 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XqW1c-0002vO-Vw for mharc-bug-texinfo@gnu.org; Mon, 17 Nov 2014 18:48:05 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqW1V-0002ie-LL for bug-texinfo@gnu.org; Mon, 17 Nov 2014 18:48:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqW1P-0002qN-96 for bug-texinfo@gnu.org; Mon, 17 Nov 2014 18:47:57 -0500 Received: from aibo.runbox.com ([91.220.196.211]:42993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqW1P-0002pq-3h for bug-texinfo@gnu.org; Mon, 17 Nov 2014 18:47:51 -0500 Received: from [10.9.9.206] (helo=mailfront02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1XqW1N-0007t4-8b for bug-texinfo@gnu.org; Tue, 18 Nov 2014 00:47:49 +0100 Received: from 70-36-239-128.dsl.dynamic.fusionbroadband.com ([70.36.239.128] helo=toshie.bothner.com) by mailfront02.runbox.com with esmtpsa (uid:757155 ) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) id 1XqW1D-0002ux-5f for bug-texinfo@gnu.org; Tue, 18 Nov 2014 00:47:39 +0100 Message-ID: <546A8917.10500@bothner.com> Date: Mon, 17 Nov 2014 15:47:35 -0800 From: Per Bothner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: real subscripts and superscripts? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.220.196.211 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 23:48:03 -0000 Currently texinfo only supports subscripts and superscripts in @math, which are only effective in tex mode. This is unfortunate since both HTML and DocBook support them. Are real subcripts/superscripts planned? I can see two ways to do it: (1) Parse @math to extract the ^ and _ characters and turn them into the correct HTML/DocBook elements. This requiring parsing tex math, which is non-trivial. Also, the result is probably wrong if the raised/lowered text contains actual text (as supposed to numbers or math symbols). (2) Introduce new @sub and @sup commands (or @subscript/@superscript if you want to be more verbose - and follow DocBook). The effect of (say) @sup{TEXT} would be: In info or plaintext: ^TEXT In HTML: TEXT In DocBook: TEXT In XML: I suggest TEXT In TeX inside @math: ^{TEXT} In TeX otherwise: use a macro that raises the text and reduces the font-size -- --Per Bothner per@bothner.com http://per.bothner.com/ From MAILER-DAEMON Tue Nov 18 18:46:12 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XqsTM-0001QH-0e for mharc-bug-texinfo@gnu.org; Tue, 18 Nov 2014 18:46:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqsTD-0001OP-0i for bug-texinfo@gnu.org; Tue, 18 Nov 2014 18:46:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqsT0-0008Ka-KZ for bug-texinfo@gnu.org; Tue, 18 Nov 2014 18:46:02 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:55694 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqsT0-0008K4-Dy for bug-texinfo@gnu.org; Tue, 18 Nov 2014 18:45:50 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAINjdUp031162; Tue, 18 Nov 2014 16:45:40 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAINjdth031160; Tue, 18 Nov 2014 23:45:39 GMT Date: Tue, 18 Nov 2014 23:45:39 GMT Message-Id: <201411182345.sAINjdth031160@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: per@bothner.com Subject: Re: real subscripts and superscripts? In-Reply-To: <546A8917.10500@bothner.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 23:46:09 -0000 Hi Per, Are real subcripts/superscripts planned? There has been no specific plan to date, for this or any of the many other things lacking in Texinfo. Your message is very helpful in that regard. (2) Introduce new @sub and @sup commands (or @subscript/@superscript @sub and @sup sound good to me. The only complication I can think of is that \sup already exists in TeX (typesets the mathematical operator "sup", three roman letters). It would not be feasible to distinguish @sup from \sup, although of course it would be trivial to create \supop or some such to still be able to access it. I rather suspect that the number of existing Texinfo documents that use TeX's \sup is zero. In info or plaintext: ^TEXT In HTML: TEXT In DocBook: TEXT In XML: I suggest TEXT In TeX inside @math: ^{TEXT} In TeX otherwise: use a macro ... That all sounds fine to me. I only wonder about Info/plaintext needing some kind of delimiter in the case where TEXT is multiple characters. As in x@sup{2y} is different from x@sup{2}y, but both would be represented by x^2y given the above. Maybe x@sup{2y} should go to x^(2y) in Info. That's a math example so I suppose people should use @math, although you can be sure that once the feature exists, it will get (ab)used for everything possible. I'm not sure if there are examples of textual super/subscripts where parens or something would be desirable. I can't think of any; something like 1@sup{st} is readable enough as 1^st (ugly enough, too). Patrice, Gavin, wdyt? Thanks, Karl From MAILER-DAEMON Tue Nov 18 19:17:35 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xqsxi-0006ER-TP for mharc-bug-texinfo@gnu.org; Tue, 18 Nov 2014 19:17:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqsxa-0006Dw-9H for bug-texinfo@gnu.org; Tue, 18 Nov 2014 19:17:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqsxS-0000h6-K1 for bug-texinfo@gnu.org; Tue, 18 Nov 2014 19:17:26 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:33720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqsxS-0000eO-BW for bug-texinfo@gnu.org; Tue, 18 Nov 2014 19:17:18 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAJ0EjA9026937; Wed, 19 Nov 2014 01:14:45 +0100 Date: Wed, 19 Nov 2014 01:16:53 +0100 From: Patrice Dumas To: Karl Berry Subject: Re: real subscripts and superscripts? Message-ID: <20141119001653.GE14015@free.fr> Mail-Followup-To: Patrice Dumas , Karl Berry , per@bothner.com, bug-texinfo@gnu.org References: <546A8917.10500@bothner.com> <201411182345.sAINjdth031160@freefriends.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411182345.sAINjdth031160@freefriends.org> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 546BE0F5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 00:17:33 -0000 On Tue, Nov 18, 2014 at 11:45:39PM +0000, Karl Berry wrote: > Hi Per, > > In info or plaintext: ^TEXT > In HTML: TEXT > In DocBook: TEXT > In XML: I suggest TEXT > In TeX inside @math: ^{TEXT} > In TeX otherwise: use a macro ... > > That all sounds fine to me. I only wonder about Info/plaintext needing > some kind of delimiter in the case where TEXT is multiple characters. > As in x@sup{2y} is different from x@sup{2}y, but both would be > represented by x^2y given the above. Maybe x@sup{2y} should go to > x^(2y) in Info. In math, Info/Plaintext already relies on {} to separate "arguments" because it is how TeX does. So, I think that in @math, when doing Info x@sup{2}y should be x^{2}y. > That's a math example so I suppose people should use @math, although you > can be sure that once the feature exists, it will get (ab)used for > everything possible. I'm not sure if there are examples of textual > super/subscripts where parens or something would be desirable. I can't > think of any; something like 1@sup{st} is readable enough as 1^st (ugly > enough, too). Out of @math, I am not sure. I think that using () or {} would be ugly, but then your example above shows the case of an ambiguous case. I would really like to avoid having to known if there is something after the @sub or @sup to add {} or () to disambiguate, and do not do it if there is a space. Maybe I would favor using x^{2}y in textual context too, since there is no good solution, and it is simpler to implement and explain as it is the same as in @math. -- Pat From MAILER-DAEMON Wed Nov 19 14:06:08 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrAZs-0002uu-2F for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:06:08 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrAZo-0002un-00 for bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:06:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrAZj-0002PM-Qg for bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:06:03 -0500 Received: from mail-ie0-x22a.google.com ([2607:f8b0:4001:c03::22a]:42374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrAZj-0002N3-Lb for bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:05:59 -0500 Received: by mail-ie0-f170.google.com with SMTP id rd18so1158602iec.1 for ; Wed, 19 Nov 2014 11:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XenCqQSkaHyxD+FUcNeI4zm/HTgeItPBRpXjjJXw/b4=; b=cbcmGGbYQNEqV5oJbpNvUvq5nL0yvM/Eu8/6oose/FY4gky0PDq0ilwWR2rXLEz3lz Sd87LGaXrMkU1lH60jrpuWLuJGAZAEKL0VLBjFGTWvku0YWZKstwj2o62ZSGKDyCb+to MDlqHdF6lM3ET3WjYL3HQF2g44uWjIvX2PNACsurduNf0fEqmFpNXnZ8NgtOcOvDIR6V RyMwrbnF+/JqgQg7XhXedsRUWLsz/v6k4EngdKXWabkjguYU0rLEVFKNGK3g/Sz7IoZ2 2A0lXh9p5QJUHE0UiS4TZF6OGVma44RyyiH/v3zQaRXMBWM1TdCX3PsAgLg8rm2wWsdu owQA== MIME-Version: 1.0 X-Received: by 10.42.253.195 with SMTP id nb3mr4222846icb.34.1416423958276; Wed, 19 Nov 2014 11:05:58 -0800 (PST) Received: by 10.107.170.231 with HTTP; Wed, 19 Nov 2014 11:05:58 -0800 (PST) In-Reply-To: <54696E8C.1030403@softwaresam.us> References: <54696E8C.1030403@softwaresam.us> Date: Wed, 19 Nov 2014 19:05:58 +0000 Message-ID: Subject: Re: 'raggedright' command in HTML output From: Gavin Smith To: Mahlon Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22a Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:06:06 -0000 On Mon, Nov 17, 2014 at 3:42 AM, Mahlon wrote: > According to the documentation, the @raggedright command does not apply to > info and HTML output, obviously because the command applies only to output > formats that can produce 'justified' text. The 'info' output correctly > processes the paragraph as ordinary paragraph text. Note however, that for > some reason, the HTML converter produces no output for the paragraph. The patch below appears to fix it, although I don't understand everything that is going on and if there are other changes that need to be made as well. At line 7289 this will make the condition be true because it will have been initialized at line 4609 (revision 5923). Index: tp/Texinfo/Convert/HTML.pm =================================================================== --- tp/Texinfo/Convert/HTML.pm (revision 5923) +++ tp/Texinfo/Convert/HTML.pm (working copy) @@ -2482,6 +2482,7 @@ return $content; } +$default_commands_conversion{'raggedright'} = \&_convert_command_noop; $default_commands_conversion{'flushleft'} = \&_convert_command_noop; $default_commands_conversion{'flushright'} = \&_convert_command_noop; $default_commands_conversion{'group'} = \&_convert_command_noop; From MAILER-DAEMON Wed Nov 19 14:31:49 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrAyj-0002tk-3J for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:31:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrAyf-0002sE-Nk for bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:31:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrAye-0004F6-Kg for bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:31:45 -0500 Received: from mail-ie0-x22b.google.com ([2607:f8b0:4001:c03::22b]:64393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrAye-0004Er-Ez for bug-texinfo@gnu.org; Wed, 19 Nov 2014 14:31:44 -0500 Received: by mail-ie0-f171.google.com with SMTP id rl12so1192404iec.30 for ; Wed, 19 Nov 2014 11:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5dstt0WHdlo9Z8OlaFuvnu4bqZlUzUYukZVniv0ddHQ=; b=ncqsdpw+VUhindD6/sYS4qIIS1/SLTeCrw+KQXSnh2qA8jWDJ77pey4lQwI+zK2WyY GoK7PuYrDuGNMGjCY+Rgw0WUp7Ki36q9N2c34ED7yDDEMV9p9hs/04cah/gQHwVKKhwc NHO1wKCbn3PGoJpl2Gw/10BpY6MPcTMzBaMBrYSYmKH6cxTf0oGeRf/8kWv2KO1drWQh fNPtuQWPECk+YNJowSKPrLxCe8qS/+Zbzhxp9v2Le2w6cv5ZlqCH2Xenu7bg9X+TpRlI xdAML+UUpc9etHy8SGSRJw+PAuzGPh3QGg6txfBvclFMME8mTMbcNMbiMwckNCm+BEOG 7mjg== MIME-Version: 1.0 X-Received: by 10.50.137.1 with SMTP id qe1mr5265808igb.18.1416425503954; Wed, 19 Nov 2014 11:31:43 -0800 (PST) Received: by 10.107.170.231 with HTTP; Wed, 19 Nov 2014 11:31:43 -0800 (PST) In-Reply-To: <201411162340.sAGNeCjL017157@freefriends.org> References: <201411162340.sAGNeCjL017157@freefriends.org> Date: Wed, 19 Nov 2014 19:31:43 +0000 Message-ID: Subject: Re: texinfo documentation? bug From: Gavin Smith To: Karl Berry Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22b Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:31:47 -0000 On Sun, Nov 16, 2014 at 11:40 PM, Karl Berry wrote: > I know it seems weird, but otherwise there is no explanation for the > example as a whole being indented. I don't remember, but I may have > added the aside precisely because someone wondered about that (or maybe > it was there all along, I dunno). Anyway, I don't see a good way to > write the example without it, because the whole point is to show how to > not-indent a first line after an @example and the example as a whole > wouldn't come out right without being set off somehow. I suppose I > could add ", thus this example's indentation as a whole" to the aside > but I suspect that would just make things worse. Do you see a good > revision to make? I see what you mean, so it needs to explain why the example is indented despite the presence of @noindent. Although "@display" and "@end display" don't actually appear in the example you might imagine that they are if you are not thinking too clearly. It depends how you interpret "This whole example is between" - whether the things it is between are part of the example, or outside of the example. It might be better not to include the explanation itself within the indented example, but put it after. Something like the following, maybe with less clumsy wording: Index: texinfo.texi =================================================================== --- texinfo.texi (revision 5923) +++ texinfo.texi (working copy) @@ -8990,8 +8990,7 @@ @@noindent This line is not indented. As you can see, the beginning of the line is fully flush left with the line -that follows after it. (This whole example is between -@@code@{@@@@display@} and @@code@{@@@@end display@}.) +that follows after it. @end group @end example @@ -9006,11 +9005,14 @@ @noindent This line is not indented. As you can see, the beginning of the line is fully flush left with the line -that follows after it. (This whole example is between -@code{@@display} and @code{@@end display}.) +that follows after it. @end display +@noindent +(The example above is indented as a whole in this manual to mark it as +an example.) + To adjust the number of blank lines properly in the Info file output, remember that the line containing @code{@@noindent} does not generate a blank line, and neither does the @code{@@end example} line. From MAILER-DAEMON Wed Nov 19 16:30:14 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrCpK-00080k-I4 for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 16:30:14 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrCpD-0007xy-K1 for bug-texinfo@gnu.org; Wed, 19 Nov 2014 16:30:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrCp7-0001qr-C1 for bug-texinfo@gnu.org; Wed, 19 Nov 2014 16:30:07 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:35214) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrCp7-0001ql-19 for bug-texinfo@gnu.org; Wed, 19 Nov 2014 16:30:01 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAJLRTlK001026; Wed, 19 Nov 2014 22:27:29 +0100 Date: Wed, 19 Nov 2014 22:29:45 +0100 From: Patrice Dumas To: Gavin Smith Subject: Re: 'raggedright' command in HTML output Message-ID: <20141119212945.GA19046@free.fr> Mail-Followup-To: Patrice Dumas , Gavin Smith , Mahlon , Texinfo References: <54696E8C.1030403@softwaresam.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 546D0B41.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 21:30:13 -0000 On Wed, Nov 19, 2014 at 07:05:58PM +0000, Gavin Smith wrote: > On Mon, Nov 17, 2014 at 3:42 AM, Mahlon wrote: > > According to the documentation, the @raggedright command does not apply to > > info and HTML output, obviously because the command applies only to output > > formats that can produce 'justified' text. The 'info' output correctly > > processes the paragraph as ordinary paragraph text. Note however, that for > > some reason, the HTML converter produces no output for the paragraph. > > The patch below appears to fix it, although I don't understand > everything that is going on and if there are other changes that need > to be made as well. At line 7289 this will make the condition be true > because it will have been initialized at line 4609 (revision 5923). > > Index: tp/Texinfo/Convert/HTML.pm > =================================================================== > --- tp/Texinfo/Convert/HTML.pm (revision 5923) > +++ tp/Texinfo/Convert/HTML.pm (working copy) > @@ -2482,6 +2482,7 @@ > return $content; > } > > +$default_commands_conversion{'raggedright'} = \&_convert_command_noop; > $default_commands_conversion{'flushleft'} = \&_convert_command_noop; > $default_commands_conversion{'flushright'} = \&_convert_command_noop; > $default_commands_conversion{'group'} = \&_convert_command_noop; That looks good. The only thing that come to my mind is that, sometime it may be better to use categories of @-commands defined in Texinfo/Common.pm, but in that case, the raggedright is in the "align_command" hash, but center is there too, so I think your patch is best. In the HTML converter, all the @-commands are associated with function references to make them configurable. Also, please check that the test work correctly before commiting, and if not regenerate them. -- Pat From MAILER-DAEMON Wed Nov 19 17:42:33 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrDxJ-0005aY-Lg for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 17:42:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrDxB-0005Yc-G3 for bug-texinfo@gnu.org; Wed, 19 Nov 2014 17:42:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrDx4-0008S5-2p for bug-texinfo@gnu.org; Wed, 19 Nov 2014 17:42:25 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:47840 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrDx3-0008Re-RC for bug-texinfo@gnu.org; Wed, 19 Nov 2014 17:42:18 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAJMgE3a002828; Wed, 19 Nov 2014 15:42:14 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAJMgE17002826; Wed, 19 Nov 2014 22:42:14 GMT Date: Wed, 19 Nov 2014 22:42:14 GMT Message-Id: <201411192242.sAJMgE17002826@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: gavinsmith0123@gmail.com Subject: Re: texinfo documentation? bug In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 22:42:31 -0000 Agreed, I'll make a change along these lines. Thanks. k From MAILER-DAEMON Wed Nov 19 18:07:27 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrELP-0001k2-AX for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 18:07:27 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrELH-0001i5-Fj for bug-texinfo@gnu.org; Wed, 19 Nov 2014 18:07:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrELB-0007aa-B3 for bug-texinfo@gnu.org; Wed, 19 Nov 2014 18:07:19 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:48220 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrELB-0007aW-2m for bug-texinfo@gnu.org; Wed, 19 Nov 2014 18:07:13 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAJN74jd005236; Wed, 19 Nov 2014 16:07:04 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAJN743h005234; Wed, 19 Nov 2014 23:07:04 GMT Date: Wed, 19 Nov 2014 23:07:04 GMT Message-Id: <201411192307.sAJN743h005234@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: pertusus@free.fr Subject: Re: real subscripts and superscripts? In-Reply-To: <20141119001653.GE14015@free.fr> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:07:25 -0000 Maybe I would favor using x^{2}y in textual context too, since there is no good solution, and it is simpler to implement and explain ... Ok by me. Doing the simple way (always add braces) first seems reasonable; if it turns out that the feature gets used enough and people really don't like it, the output can always be tweaked later. I can add these to texinfo.tex and texinfo.texi, etc., easily enough. Do you have time to add it to makeinfo? Thanks, Karl From MAILER-DAEMON Wed Nov 19 22:35:10 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrIWU-0002V3-M6 for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 22:35:10 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrIWM-0002QH-6w for bug-texinfo@gnu.org; Wed, 19 Nov 2014 22:35:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrIWF-0007N1-1C for bug-texinfo@gnu.org; Wed, 19 Nov 2014 22:35:02 -0500 Received: from p3nlsmtpcp01-02.prod.phx3.secureserver.net ([184.168.200.140]:45044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrIWE-0007MZ-Pn for bug-texinfo@gnu.org; Wed, 19 Nov 2014 22:34:54 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-02.prod.phx3.secureserver.net with : CPANEL : id HfXu1p00h2RsmEA01fXuCz; Wed, 19 Nov 2014 20:31:57 -0700 Received: from [124.207.38.54] (port=33109 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XrIW5-0004ro-Tt for bug-texinfo@gnu.org; Wed, 19 Nov 2014 20:34:46 -0700 Message-ID: <546D614C.60401@softwaresam.us> Date: Thu, 20 Nov 2014 11:34:36 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: HTML output for @quotation + @author Content-Type: multipart/alternative; boundary="------------040008050901040007030807" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.140 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 03:35:09 -0000 This is a multi-part message in MIME format. --------------040008050901040007030807 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 20 Nov 2014 RE: HTML output for @quotation + @author commands VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64) BUG: There are two issues for the HTML output when using the @author command within a @quotation: 1) A blank line is generated between the quotation itself and the author's name. This extra line is not present in the info output. 2) The author's name (and the emdash) are centered on the page. This mirrors the info output, but the author's name looks isolated (lonely?) in the HTML output, especially for a short quotation, because the name may be considerably beyond the quotation itself. For the following source: @quotation "A penny saved is a penny earned." @author Benjamin Franklin @end quotation currently, the HTML looks like this:

"A penny saved is a penny earned."

Benjamin Franklin
Logically, the 'author' output should be _inside_ the

, thus eliminating the extra blank line _and_ beautifying the horizontal alignment. For example:

"A penny saved is a penny earned."
Benjamin Franklin

Note that the '3.2em' indentation is used in the above example because it agrees with all the other indentations generated by the texi-to-HTML converter. Note also that depending on where the last line of the word-wrrapped quotation naturally ends, the
_might_ generate an extra blank line anyway, but I don't think we can do anything about that... Cheers, Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------040008050901040007030807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

20 Nov 2014

RE: HTML output for @quotation + @author commands

VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

BUG:

There are two issues for the HTML output when using the @author command within a @quotation:

1) A blank line is generated between the quotation itself and the author's name. This extra line is not present in the info output.

2) The author's name (and the emdash) are centered on the page. This mirrors the info output, but the author's name looks isolated (lonely?) in the HTML output, especially for a short quotation, because the name may be considerably beyond the quotation itself.

For the following source:

@quotation

"A penny saved is a penny earned."

@author Benjamin Franklin

@end quotation


currently, the HTML looks like this:

<blockquote>

<p>&quot;A penny saved is a penny earned.&quot;

</p></blockquote>

<div align="center">&mdash; <em>Benjamin Franklin</em>

</div>



Logically, the 'author' output should be inside the <blockquote><p>, thus eliminating the extra blank line and beautifying the horizontal alignment. For example:

<blockquote>

<p>&quot;A penny saved is a penny earned.&quot;<br>

<span style="margin-left:3.2em">&mdash; <em>Benjamin Franklin</em></span>

</p></blockquote>


Note that the '3.2em' indentation is used in the above example because it agrees with all the other indentations generated by the texi-to-HTML converter. Note also that depending on where the last line of the word-wrrapped quotation naturally ends, the <br> might generate an extra blank line anyway, but I don't think we can do anything about that...


Cheers,
Mahlon



--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------040008050901040007030807-- From MAILER-DAEMON Wed Nov 19 23:08:31 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrJ2l-0001IL-AB for mharc-bug-texinfo@gnu.org; Wed, 19 Nov 2014 23:08:31 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrJ2c-00015o-Gm for bug-texinfo@gnu.org; Wed, 19 Nov 2014 23:08:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrJ2V-0003fD-Gh for bug-texinfo@gnu.org; Wed, 19 Nov 2014 23:08:22 -0500 Received: from p3nlsmtpcp01-04.prod.phx3.secureserver.net ([184.168.200.145]:59452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrJ2V-0003ek-9E for bug-texinfo@gnu.org; Wed, 19 Nov 2014 23:08:15 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-04.prod.phx3.secureserver.net with : CPANEL : id Hg6C1p00j2RsmEA01g6CAo; Wed, 19 Nov 2014 21:06:15 -0700 Received: from [124.207.38.54] (port=33119 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XrJ2M-00027f-3W for bug-texinfo@gnu.org; Wed, 19 Nov 2014 21:08:06 -0700 Message-ID: <546D691A.4080706@softwaresam.us> Date: Thu, 20 Nov 2014 12:07:54 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: Orphaned Style Definitions Content-Type: multipart/alternative; boundary="------------080300020403020507080701" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.145 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 04:08:29 -0000 This is a multi-part message in MIME format. --------------080300020403020507080701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 20 Nov 2014 RE: Orphaned style definitions VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64) This is not really a bug, just a heads-up: There is a block of styles defined in the header of the HTML output. Two of these styles: pre.menu-comment {font-family: serif} pre.menu-preformatted {font-family: serif} are defined but never invoked. Instead, menus in the HTML are generated using: ... which is certainly a better method. Clearly, these orphaned style definitions do no harm, and you may have some idea for using them in the future, but if not, they could be eliminated from the
--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------080300020403020507080701-- From MAILER-DAEMON Thu Nov 20 00:21:04 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XrKAy-0003Hl-LG for mharc-bug-texinfo@gnu.org; Thu, 20 Nov 2014 00:21:04 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrKAp-0003Gh-SH for bug-texinfo@gnu.org; Thu, 20 Nov 2014 00:21:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrKAj-0000El-2f for bug-texinfo@gnu.org; Thu, 20 Nov 2014 00:20:55 -0500 Received: from p3nlsmtpcp01-01.prod.phx3.secureserver.net ([184.168.200.138]:46597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrKAi-0000Eb-OO for bug-texinfo@gnu.org; Thu, 20 Nov 2014 00:20:48 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-01.prod.phx3.secureserver.net with : CPANEL : id HhJe1p00v2RsmEA01hJeA2; Wed, 19 Nov 2014 22:18:41 -0700 Received: from [124.207.38.54] (port=33139 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XrKAe-0004hg-8p for bug-texinfo@gnu.org; Wed, 19 Nov 2014 22:20:44 -0700 Message-ID: <546D7A27.3090907@softwaresam.us> Date: Thu, 20 Nov 2014 13:20:39 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bug-texinfo@gnu.org Subject: HTML Output for @table and @multitable Content-Type: multipart/mixed; boundary="------------070900000900010109070500" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.138 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 05:21:02 -0000 This is a multi-part message in MIME format. --------------070900000900010109070500 Content-Type: multipart/alternative; boundary="------------050706020001010806090309" --------------050706020001010806090309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 20 Nov 2014 RE: HTML output for @table and @multitable VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64) /I sincerely apologize for monopolizing your time. Only one more to report after this one, I promise (but it's a big one)./ BUG: Without the application of CSS style, the HTML output for both @table and @multitable could be considered unacceptable for two reasons: 1) the formatting of the HTML output is rather embarrassing, and 2) it doesn't much resemble the 'info' output, neither in line spacing nor in column spacing Both of these issues can be corrected with CSS style alone, but you might consider what could be done inside the texi-to-HTML converter. For the CSS, see our definitionsof the HTML and
elements in 'infodoc-styles.css'. Included in the attachment: [2014_11_20]$ tar -tvf bug_report_2014_11_20.tar.bz2 -rw-r--r-- Mulan/Mulan 6555 2014-11-20 12:52 bug_report.texi -rw-rw-r-- Mulan/Mulan 5657 2014-11-20 12:55 bug_report.info -rw-rw-r-- Mulan/Mulan 12293 2014-11-20 12:55 bug_report.html -rw-rw-r-- Mulan/Mulan 10782 2014-11-20 13:00 bug_report_css.html -rw-rw-r-- Mulan/Mulan 29510 2014-11-20 13:03 infodoc-styles.css -rw-r--r-- Mulan/Mulan 214 2014-11-20 12:55 Makefile Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------050706020001010806090309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

20 Nov 2014

RE: HTML output for @table and @multitable

VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

I sincerely apologize for monopolizing your time.
Only one more to report after this one, I promise (but it's a big one).


BUG:

Without the application of CSS style, the HTML output for both @table and @multitable could be considered unacceptable for two reasons:

1) the formatting of the HTML output is rather embarrassing, and

2) it doesn't much resemble the 'info' output, neither in line spacing nor in column spacing

Both of these issues can be corrected with CSS style alone, but you might consider what could be done inside the texi-to-HTML converter.

For the CSS, see our definitions of the HTML <table> and <dl> elements in 'infodoc-styles.css'.
Included in the attachment:

[2014_11_20]$ tar -tvf bug_report_2014_11_20.tar.bz2

-rw-r--r-- Mulan/Mulan 6555 2014-11-20 12:52 bug_report.texi

-rw-rw-r-- Mulan/Mulan 5657 2014-11-20 12:55 bug_report.info

-rw-rw-r-- Mulan/Mulan 12293 2014-11-20 12:55 bug_report.html

-rw-rw-r-- Mulan/Mulan 10782 2014-11-20 13:00 bug_report_css.html

-rw-rw-r-- Mulan/Mulan 29510 2014-11-20 13:03 infodoc-styles.css

-rw-r--r-- Mulan/Mulan 214 2014-11-20 12:55 Makefile



Mahlon



--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------050706020001010806090309-- --------------070900000900010109070500 Content-Type: application/x-bzip; name="bug_report_2014_11_20.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bug_report_2014_11_20.tar.bz2" QlpoOTFBWSZTWZgw/kQANSd////85/H7////f/f//v////rAAABgASABABABAACUAABIYEmb 3nHsJvfPcBfYuwaL7aMQ23thVUkvZpXttitTTIEAFS7Fr13Xvs98Ylk9fF2a+7tuva81G+64 eUA0o1XIDpntZd27ud7u971ve97z73X23vu6kdbTRPbT25OtoWq9Z727tAZI52ubrvr672+2 647quxqWYbZu7qq97vd7vTZKzZ7dzTb17nu1lgqhjY0yttZbaGdML7bw1jW33PgA7ve70N3X sA6vR6b1u9HO2srGxqTruPoSRBAARomE0IwQTTE001MJNPKeieiaPTRGnqYTRoYhiMhoACU0 EEEBIxNT1GmmiZT9GiE9E9Q0Gg8pkNBoAANAA0AABIkpqT2lG9KeUyBkHqGhoHqHlBozUaHq B6gGQADI0yDQAAeoIUiQQTQU8mU9U9NTwp6maR6mmnoQaNNNGTINNDRoAAAAAABEkgmJoIAE NTaBTxGpo1PTUyGmjynqPUNNA0xqAAAAAABUSQhAjTTRT0nkGSZMjUntATKP0UPUPKNqHlNA YjIAAAAeoM8V/P0s7Ql5rIp684pwhNDqACHpwKDAt24tjxlhEKBvH5sLHxtfY+xai4cTMgMS DTAyi1MuixagAgTPm6RzfXSODowQclO5lWJORGTssPofS+jcIHofNgr+IbFnI0/XE96a/YEB fq9z/b5r2/BZfVi5NNZEHGiwZwdlaDDAmGSF/i/Hl1WdX5/1Q+OT23k/zx5uDdHNwP00Ty92 yzVth79695oSf9fR6oWT9/45azx0Bx9njrF1bxzpDpWmOX+HLsOqs0HPiLn2jw6fP31k7CDa bPBf6bj3dNluqmS/UBBoPX4k/y5h0ywFwyUMlDJsmpQxkaXIGgmAOtkzAtUtLarMxIgxpUyQ 8Eg0asSbO9MQ1K9gHbznzaMa+p7+fx8jJ48XvWFrDHDdVVqciIYMPIQak08wS4khMhCOxd6B oZCUuixp79DFDJU7OiXcX5Tvo7fQfbt+datJq71VNCDtQ5KDpBawbmJhi7eK7dGlHydkIHmf Z+lwOmodmuRFM0ZE3EtVapimNGFasNttpttpjbbY6i8iyYlTND+L/D7xG6vK6KYxXJT2lbKp YnkVjYxOFQqqoqjCgYQxIxAsEQQtIwsRMDDDAhMaigjDt6ub4W+3zTO/tLodJpVGJNkc7UZe i3dkZMFZ8N2yNnmmNCXt+bbfh7/NlXZo1vObsPbkemf7m2FrUWvqk8ct1vWmimah/Dd5ZD8M M4xuHCjT9sdSxD9bM1l7Aww1HwUEiP+e+PuXPftdYR6SDDnYZvfFDhx+fZAdDFMhwg4Ui9fT 4fBypKFjSGuuTwMIDjsM6NjJceqpeNxm9sJTt7qJ8GAptjH3m+dp6UOla7oPxsFLIKnUYAMx RT4uX65nht6mQcp590fBTRRR5Y00Dnhe9oB2Ta7u3am47ZoT4WohoUpD8U8uGWlAPX8JeHcQ Hugyej8HzDdcNrzH8+DcKItv7TMgcXPpxs7DYbG8NsXa9o+Szn9n5q6+H5sfitN7F3i9T9Ff nwbDEhZWxmg10+rCZlJ3mXDEKmeiNF7lh2Uvg3v3Toaabuoysuu+/qM1kruJE0AjaxTdetY5 UFq3Lkccm9QDkGAonxbK9UTdEUW2dCBq5+rDdP0/f/F4OcecocWT2KHaxiOn8nEjXdT1enoF MfCxfffBBqGFYdNOXkttmDpihg2uZZ9MBltceZnMuY6/ycUvDZLGh+Oeef1MR54K3mIMUPEG +vCg50R4RVEgZUARZKp1NGxvXx4cfH0mO41B570dWB9SkF9arUcqZIap8/L1a10SKGDlzysk zdruY5G+oiCZg3pShhhgzYU0WN3AeM85cXRVtxRFDRQ0pVSF7VRQrI3MFAD1wVr9+Pv/b9Zk ntNxsAsG0Sk8Z7gx0nE5BtjJiUdZUzMcdJzvmQOH5R5aqp+WEXosg1F7Bqp8sMxZ+Z4VCY0p 5Q058MER/I7szDfDkPqtdZ6M+Tu95Rg7EQJs+1qeckc2wtoroCmqt9c3uNb+cu4HPDKcC7hj 2YS7jRdnLWVRswEJECIYEmYbCD0o2+rte84R7npYfVp6LUwnxzoNhNN0OOyxogdDtryhIr1W N1vURd+XPhUbuRpAhXIKeO7Ca8Q6vT7/ehxIKI9sBH5Ir4RXFjeS+aX910ovsSxpFve4ftIb Bb82M+OnSmlUNdgLk1LHBktzARGG5GwXeLHjziYxQyEeIvZo81hIIJNwizMmzh7MfxkCDFrB wa1V1WET/c6jUZpVz9j1FUmRg5qlrVep7+BgIa/V84Gpq6tuEiIAQhCEIGqh1nzfIR9et+Zt lHVX8RkHxcA4x7NldhnfEa1KbvVlsoPUcyC/w7EaZp4t7z9dx34fi/f1CvZVuhGq6Ojvrd+8 ZvTTBmGGaLGyDNN3UPf7q/dODXBTRSwzV+3bNLZxqkiCWnip7m40lqUCTvxphzec+Irx1ens jGMY1W1h1hRwGC5CxZNsx6j2QnBRiww/ebqsRKaDk2bb7Q3dgMsr0kFO+nuLd+Ydd0OtsQpq 5zmyC7ZJJO+qkWQcMDDch/SqEXgv2c7HURdJ0ET32sEEUIeO0R5QNAZnOYCPRk2PdUo5tJQC Xg88BETCcwvgNZPpbPSc+ShsNltPFqBgpMw7devr5V7jT6+vhFREQS1QHXMoiQgQhAhCEISx 4e16uR794zy7NNGPrhxrm0h3NdgHVB0s12MiAbTUgDv3bAmRpBUa8etHX2YWKarRsKnUKSkE oS0AndFxmdmtDTRzqYDeZJfX4quQc8gigsil1sA38NsvaEpqlrt3Z7/bJWiYecOdolgbk8L3 REYUGLszrhkxwnS3g2Fc4JaIlxO2m8A+NM9vLy8PGlEQ0QEIgEkmlB3C5xv8JGfZIwrdePny vwEMFZT0xSh77KTW65A8PaEaOqjHxc9Hih3FHk1klUqfwXxzTuWUilA65xjxzFW+Z/WJKQUV bRziwTaxt1lSqALghBpzHv1uQYO194lT4aWT+1vZI8p6xvbJ7mryXB9OO9X9CC4JsXQ0wKvb CyGFKLYYHF4MGkbLQ0D0QoSjKrUlxlsupNYVJEqAYHDiDaTB0rpIcgyZo7dMsCuy7wHCeMyG vTveDsT8U/HVoQmbmsobzaaHzt40XzYzupnoyhz2lNBNQpdG/0pyrvw5zDZhez7/y+3YI4Dj NSrqteyWGoH7ZJawvFjwC2qkHhGArXdqUZRecZK3PV+iPAAtSx3g6SjctLVaEJ6aZhjPVSPo /kB8HuahRgu8dbpefEctL4n6a5pt0JFCSRjj/pPwSyOxSnrHzTTT7Schs4PzG52X3VXhzvzR DrbApfISTi16NHxHS+gxaiYQoCBoVhOIWuJUst4uDgyRfHvWz0JWpV0lnKvjEPc8Od1tZ8pt 9aeqPOx0H6Ma7Iw1UQkicva2kNUIi2flchMlsW5g9qZYyUOD0RemGyGtoSra4N0flwSogJxg qrM1ZLBdiVN1TpO7qkLgo5MRNWHKihpZvsYrsMF4GO7fszw18hCE11icSRq6hm6w/byfnuOw Xy2ros8qNFaE0yWboThStIPFweNbDhm6jGcEWZOAR2KJaAD6GIoQrXPPGb7/Zddbo5tRcPjt wv60V3PVE9aDjagy4W+AHDtDPvZfC4hYg7x5OoMs2feZb8W0CDFfTSQ0e5KsHaCJyiFjW24W PDwMrNxInfXRA7DUTzkGEGEHrglDDuAJDFkDwfrYRPf1MpGnHriQqYI3X3/m9woNkWuuztie /w74bh4vCC13OD6XlmheaqZkHLDhzy/xiq/blDAMT7gahrehM9uNTfZcBr34b+MXX9FBy6Un HAzrNaXhfoSxGtxHaE5rkmVtcTs4vpycy7ePhW821mNZWOobkniOPg5LHPIe6HXwxkDZ9/OR kwFNWVIWh15Eeg8ZIYpL76jvSGS0oC4cXmyKS6vncAJszN5qcfnwi9rY4uMuyns0ZsFkaoZ+ CaVA1wIPkYcJjc1PFEKDWYPjvcpqxoA5SpOgbIRymFrU30ludsQEsHpZqGTYOEKtVzXmXat2 HdDTch8MEsaaBTu0ptMCXe9dxuXnKBsiXwxLC2XM3NYF8mxp417KgvqnBlm4LEg9kqQKGRE8 f2Re7TGQdLdFKXC/PGYbiBVjFnztaqEdgWtKkOcMQ1S/gs5qVt4sdoYDDL37aJssNty3q7GO nKcWqyafeM8XCk3y+8TXhpYIWDq5b4pjxYNQqjrhlfbg0hWW0k2TM3S+rAcNXO6gicMvk+1D GW/LDqOeErXZ4eA2CPCGwJ47XMtIlctcFFlQli61tUsxosSg7zp7UgOkZIvmFQW20GUqpj+8 r57+Qa8aNrvYF4D7I3bCKV6MHxBu3xqsxomaUUN4G892ooArBc3fedjBKryUXyqlUH1w1Qll zbKpOD1Z3ND01Q00mYHM+dpW2Tu1zvLsrebM75TiOdlWVU5mvVCpMmjsIFkla4ECEzZTWRs+ 2XxV8Zpzs6QkBTaWCtijMFjlHTbn6BjEXPa8dabqqSs7NiHpNzBo3jV72qols7Wve/WDTxmq zM9utYJ82hFs9vRzZRvrpvYBbs0IcvCYgNFGYKCUgMQ6iKIUoZ0Ra8xQahqkVm7l8O+uCRJJ b9+r2W2fZWcvcyrM7tiqDeSSF3UnCzMokteN67+LkWvhyNmIRmJqzNnxxtgCuVq51bRTIIJp 77B2Wqpe0S49/ZMWeX0AeS72510s/ANJGzfvcH7gG1gi4IR5/bgMmg9HZMthmwzoPCXsNdW6 wXUTWHJLA9nrSJri55maLY6DnipbTod3MquevEDmxw9kXRu/y3ujSmUbziQ7XfsnfRASgV5q XJXgzwBhNwe5qKqjEFaAMbgYmGdbosns3QF6M9YcD2oDEytenc2tqXPecnZ0Tonjh0Ku6+td mudRom6zn6OIcARO1MM2NmKNWGUIfFQs47wuhaiucLfBqtFO6iaO9uGplML+DZ01By7pdqMo mqjdPZb0Qoi8oKoedYSOU9C3dNei9PUQ+JPphKSPJc75M56kOV/nkmLPRt7Pox86p1KVTyFK WfW+P2mzRq2zfW/rAcDEkfMyRYkUCqArESeKRJInMYA+nzIEjw/FS/ke+FLT6YodVjIExWHh wMY1hI+WXCBHHSjhuncVCGO/aJy/4BVUlIzWiJiwGTeaYdqmmw/zPIccqHxNz1ni2c0dDh9g wXJMkHykB3lixAQUFG4NcwGpoazwbMO9h2q2r0yfxPVMEi0lshJVVE+u/9X4JsqVqlR9BJEJ 7uj4fiAwqd7Ejk+ykbD0mIxGPzntep2NnNQ6T1FIoERHOFI4Q5mMW2ucT0QosI7yguaO6qjn c9Xbp+JnbkrQk6rt4bee7zwClabirlRNDJ6Yjl/rHRtVjrsh0VkdXNL70Npkz5tzfJq9EEl4 2R/KxwZ2SPM3ghZiHugjydnYQPEVVeIvxiQ4lCG3bo2Rk1thjGgKzsD26flGjQtGskgJk0GX Wr4mTcWEQITT9rGttu4hUdffqKHOU/mIr0+Od3p+HwR9X6Ht+21XvWh8+PbT9XzlW6Ju2gz+ ncEaDnN7WveyIEk/d93pSGAcwMoR32T/LSYlW1Ke2WSMlYwTGUocDMLDMxsHIw1YEkOjMAKK goJIIhoWgKpoOMkTTmmq0H3D5ZvajygT8loJKEHkNFDsMznueH1bMew3qLk0fE7MoNObInrN UpfvBSFczikwiaVIUd8HS3sspnvVSuoKbwf3UV8EqX5D8j3okGuT8m1lCymlVEVlzhpJ8Xr8 JRXGqUKGGd98Z26N63nTPX6fjyYExH8UiKGDLHwxGUYWSGHofDWvtTCwGfdsEYuJkhjI9ysX OWjjjA6HBbnmuXWDpLu8oUncHOcVPVJ+uV2HCH6H1IfEc3QrSHjO3j57ar9n9PkfCUpSpSqq vqfAnpPKJ6UOr6SHVIzCCoPX5DbK7Y3wYRNbD97QgnZxBBqxFCVnqhefFgGMwK/s0qHtMkCi msAKzxhvC2BsMwDfFD2CWvwyvsTmDQA43Gd5mwov8ptVyVFABXWwEIJtrWPkzI2FQguyhFJB rK8CQR93HE0jSSUbnwTtRWU+i9c21ksLkKZ7k8cIHR676qbauvbqbpcrM61vyHILFyw59goj TFr4x7Km2+LxTkJdy7ob2FebtC9hzcTN0r7lqRFLfbKkN/UafcVTSO/yWeKign2AND4MpRDj Te0Yv9q4L18vLeoh8Id9O6x3+avwJqTdGqKMXbI47nc8ztvoO0kEx6UfUL/OvQ0EIi7X8ibw CrWKb3UzS0D5GgpBJDe7HidfQzkFruO7jp0O6LntmQ656BCSFyKI4mYkl+FkkjPxDS9bIb4x /M+R7PsPEk/3q+9/PNM0/j/btjWzYqvvKSlSyXlQmokGgLpzJ0pEzpP1PyT0gptLp6/kcBG+ JzDYrpxXeEIDaJgT7UoPv6xI3+5j7wqI06YHuoiPcqAFWiwXX7fb6AUB0BGEfk+abZiPco5m E4GsCEnUBBd0/i/e+1mBuUNoVFE4LwiE6yTmibVJ4m2tsio3Jubm+iL4baSazX6/Ptu7yPtJ dQMN7ATUq7yXpvE+iguw7Htgd6GZBay4qnBhN792vyqrQwxrRts8Mba83gmUXHpi8sTO1XnA hcWBoNB3LdYZjTqXYAmbnbiFW/UKek5CLhDacXPFBe/OGCzXqENwu5M1wGhg34agWAvUOBhS 9O4wTEqGE0gg9dGlhG5nC672rxfRSKf7pvTgL9kbY3VFTJoUpUsmFoKC8lQpZCpLYXOVJQiY UZKUoJNX8w3l+EcpBvNvflnhE9JRBEyOkNhixwD2DNnCxZBi62QqZFMQWUBc5mRZVRs6sIkx rcEeXP6q+X972vN3fGDR+Twaib0+RxJ50tDUJE+xHo0Y/GCj7Qvn+gj1b8jLFIGhLRjWBxTT 6y7MFHLsg2MA44hDjObT+e9UYt7jjoddth5T+CPPcm6wX+hM0MdebtfB9M5sBHFUsIEijyQC qZalDG6i1hzW8gwNE89CZp3GXGDE4hCWxHSTjGW0H2XIugKws5jaARVoytI2lRTOw5erSD6o 19jnaB7ao+To0mqZiUDrzcUY77a/mif6KBK19VEMhMITIZQQu3MxG1ahRvwcDyoY3YwD51fJ BZXgfL0yISBLd+M4TFJykBD3Y4D0hytwLFYLIVlGffxqxvs2+g1N0Nw1AoHGEPWpc7L5uftc dAYMCJBUKSmKxUpPpn1n6npafC+2/Rlr648FSHUwrk+T0tjZUYqeZyYabMT3PxEjFhhwgNts ajQDJ4eDcb7hoelGhqJxvFwrkcxSVT/EimVHXVV6nJ62o3Vaqp6H77TRSdE8FKw0dYYPQFOT 7Dqe+nQfCqq953qKUrk+ByNzZ7Xwtnwu52sacN2x5z+N3Ox6j8iuDoqRPBZzYYYiqVSqf8yK mErSGGfG0Mo0MfkrBdKoyex9ZX63qbm6k8x8743SbJ8WYi3FMqVWVisplKqWrUVKvBisTRWm kGql7duyV0JMLgRhFuH0Dp0FNJTYSZRJLKkYZVqIwpTDCyfsh8Pq8biS/DkQeezDtK16h5Dh 8uFToQmnD1ethIN9Qt9W2DwpsGN1M4Iu+jmnCYMTE21DJQybUZugqt0ZDeRuw363ZJXa34dh 2Pjc2K0exj6H0sbPssr6DFbNmMdHD8b64hCEUMT9n61t3uZRoYfBTI1GNjqQYGKSODsYncqq qqdT6TtdrcbOjDseUcBjeTY4FDlDBwLmJQhos4wZA4xBkShWMRVRyRU7q5Ma4cOkjo7fL3eT tqpcZBiK0cchV6XLHO4hOYOTK63xi7FGQ54NV9lBcwKcAKBVCCYoEdWyl5uCxKyeqNIH0HZo NDQqSdZw2TdXe2629NjrUrCpMMMQ8ypJThz0VDRoYOTxrQrccClSg4UwYVTEMSoqVBUqSjFK TmaMclVSo3UO9ppTRGKJjZjrK2aNmpOFNmyVirDqI0TSoqlVFUk0rFJ0L3+57tvrvZ7vGT+x PXhUUp7kifo/c941/pcoiKEOZiYZONWpDIqql3Ktx8hp/G0NuMzMYtFhhcSy2BS03b762F54 2vrS7W9FxgKdZ5PsavdCf4ou2LE/2fxSQvi+Wsn/bRSij63azYwyGO9vp/L+CC0ZBn62N1a+ 8WFX4fYejefcDfzV31jcmIA0a1ZQtv2JiQE5gi8IFHjoH7ykjzVgJEhoy2Wx/DTRKpdP3kcz mwxipNnfPf1qT6MaOzhQHkDJwAy+Zn3PP+yZ3C4kR+YEiDgwJHiHED695au7vNQDxS+0Skkr 86MNkQLTEO7vAo/0XQgv2x4HP/ZpeMH0tI6XDisgqcKJk84WMfHD7tix0Z7mGRPxSiBmkRU8 R0iFLyS3Pj9xORpHmEQxxNxgfBOwiGHZ1nQ5sMYwwxhjGw23XyGiTowEMPaXHZyUBz1SGDBT YEOWJkd9B7o1Lp9ALd1V8ea/9tVdYjOlHUzMDcVJdHnlZdJKtkVMbS9KekSEmMO80YOxDYaC DR9kX6kKxSk8ZwZPdD0d8q3IkXCz4Nt28+U+n0eF9u3tcw7xYpHsMSYLIPDq8/LD1i80Q+AI inoD2a35hA/5h8HIUusTcUP+Y5mVpQ1XGkL/JyC6MAboCxZgx++8XZK6HIyL7IqNra9h2hi+ AyVVVX27+vg2abUbkWUono9s9Z1i/IeWThuZkmfboctTVJHo7uFIlgHF0SXfoCxAlRPYbAYd BwIv1fxdQWTUIK951CHc5h5d9dRiZFUB0b96HweEYDu11uhMpWB/A03TJMfH8yTsa6dzrUDi 6qUN18z4+tT2OThkarz1pcfKxQ3w74VBH6sBfvjJXDAsOoTNiaNhsIpPq2yApVLYT2lDGqsO XL2xRuXzu47w3nR6dPLVS+j1sJgexUYTSYwGj+XiHwqm5U2YwnGpvvtuupZ2lSIB3HgsDnaJ okUQ8C/XgwmKJKJdcMi3Qe1TEIe6x/jsAo2B167xUZv6q+Mo88XLGAOA0GQbGMmVjJ8ugIBw OHgx3xtjKBqdUGKw++IgI/q+rvf7tQIq6xahfCB9Ivo+jiJXafYM0ElloyQWVAXhNB0UBApj ZCZM+qn2JSkEElWV/ILKQZiYkykVRVFxOWkTtzmy8LvRsPARciIyALeon2rXBp1bhSWJ3/qM aLUW6yDKWyQ1Y/SLtXulA8YPz6UqRCA8h7+nUl8o6VFj+qPJwrAN6H3w0NNk/DCojYMBg0ol 2O6eVQxufRK/HdWT462vZ2HKJ9QyGRlFR4PETjJSuCJIYQOiJpbGBBwmCXDaTAiKRT84RdTQ r1AwQRaWLxINcKHNvuyHneKpYEI80PdHFdGCp8tqNrpqGAUEbzqU2KnUKdvNs/dlrx2JJ+/d ncfnKIt4vgLjACAdIOeYd9b4WqBVW6JdZ4PE0qeLl2NnjW6NkYSilkLf9lZbKl/NkDKjlcTx lwU4RslOtqI1aZrMKHgrgHJW5fpCFgMhMVJOFlKXmiaDY6NR2upffF1GXL0Ose2hDNFhBeoK aJGimsUMiBMx3IpcG0P04pqcd8BSzs4YmS4hzpwxDAMC8LxDiHStRNrGFIsh7iB09Amu6AbO bwsXx50QvIMIqLnla7u/o7pvmRndqVlasVYxVWDs0ZyHNp6xJhhrALSPNBLc16ZEzBE0SwpA mc3eM7r48ydqRydm/SdLBONOtNFdlxDQ1JkdmznvJwcyxI8s9ZDgmzUh8jnCg3r2TItkZgQY QgHTE+Ok++jpBXTzx8h84p8rrkp15R2JHN/A2R4Uj3Zw0Khkm5qdUTNtc769kDiy2SW8KI3o wJvrWh6U2irD81+eVpn0K0NsAtuiS7s4FmajcvWGVIHkch8WxAZvR50wR3hWHYCpZuP/bqA3 501/9/eBc3QGB78cEK9GJ9eU70fYxR5aSIikCRZVVbbLe6MfLdxUMMnoXGi0+8RYQqQkXHOU EH22E6LB4sBwCZiXFJxYN95i559GtM1ZqzRdGYzMhZir59kaVKptmTZrC61NVcXRFUlBwQ4Q QS97nag3wDDNgD7LTfVUm1yzEjLcYw0CBpYosbFCZ5bHKqFeAbEMfnI7Pi7A6hyiJJgZYCZM kehyPBYaApU8IWhCmgoaAoaV6DGgB8Odl+nuzfNj24BpCEBfXB7DjWsU5CAEMOgsOUHiRX42 EIuEVvFqBSJ3E7brMdeuQ9Rsd1PnV2HWTHqkl9UPA9RYnI+Vxu2hgdtFKReWKQgtDbYKpkZE o4DktJASe35dBqoPe670G1hoYVsVYtFehVubq20ymBjZrak1asgG2OBiUMvysGwDOywbnicp TiraUsFIEFmGVCZBvQ7C0kMc+7E1NO8MK1DnGYtIR0ALKgiS65qDQ4zlu63WOmcU6g1g8EjS LG3O5Y0kwNnQsnOEjCiSYEEUtcvDQPaWAuE5cWcQ7QtcbaB3VFd9W3DEWFjvdb01O0dh053y dNSYpwrhjQBhJD6kaip6YAcYuWWapRqHJLI1kjw2syjRUNjizTIfF67kmwkmLmSAxqT0usnr CABahhpZItDhWDNc1oyXu8d8tatXe3c95ZPC8+x3jxI6x6ELh7bFXHGbOnijg2EzmUAOBADk HYJltpHVMch2jx5XUQ5O+eTx11+OxLVAntlJFsWIUEf1uOQ49ngepsuYDp+ilvqdPPjrpZLF O0LUfOleUt0sdGw7kw7qNsd3MO07unXnVOVNpNKM8760uKhdGpTmG3JUKAuAtAJHsrmsmFRw 2yQwmxujDiTaJrTbVT1UGlaberOmmCYLygysa60newHpgJCxjPD0ULnNZtYu2WCDjA1juvGw 2zm8IXBdQH3XCINkzDqyHTPxbYeJmrMEnHlcL0D2s0Bgeg5OGachM2tNkUUCB9s8TMUZQrYC jem1Qy01B42liAy++mmLs1Ek8ThbRow4XEzYULhkka0sPZx/WoZrGYuEoGjkzxo+oZdaJIB0 Ajdwvy4rLFPayTNrqtb7YxN7GHHPqWUENvUMwiI6JjRMc7aacVjaOcREjQ2oPwzrNodxc77X 2DLWBZUNBBZjlylUw9swwPi7c12PJtqNO7lps6iqqqZOF1GmGGKVVVUpO5XuNpK7cXqyZjPI 8OfS4SSFu7NbMzLyJnBCDBoMG4TFCSStTkDBqMwqTAJK5Fuata0QDv20pFVEXUFTks/vi87x vxkvlHkRtHdC6QWRNxU0UYTRM0ccG7JW1R168LsplS86o1hunBSlKKpUppWBhBc/OrikpKQ0 LWMhgPNlJiWOdhLMN7J4/Ewv2JQiAOCOEKxXY5r1FyGUwZAoOg59puhWxLh6mY4MdQnKRwo9 vk683/88B+6qydI+g5w5li2yTjbS58dq57WDCDQZkpptXPK2AbLPMQMX80MPfQLzLJtDSHFF mZ1EMWYBNKBGr8QfEC2dmpgvf2M1AYOmZl8IfEvDyiWSgtc43DVRydj+jvDvt6piSLllZmZV iOrDoLz3eEip8/uWJaqYaTA9jwNG1ItBskd0Qc4x0du23dHG3WkOhDHNeO8eROaaoLtwfZAJ CbW12zSDjtGZQ2NCKG6cUrNeSENorNXM7mEFh3YQUqTj0oiMcxzpc1zgboNL0Bb22OuEZku+ 0tOONXWpPfL7pVxr2zPEWv1jMMOEGe5C0qcOLyb7gAvEkhmTz6Aiy+L5o76pLAR3alBachN0 tEKnfUxOhlOmSBZXQxD3OFbbnG7thvo7xhqqGmJVKFg/HqBnfjZs7twYvnQihmbUoOOzbvWH m8DeWliVLlly7szaEoEgs9dHCV6feKxcCnZxiCEBZ3E10ITG8E4DOTsefRoiLeGRWGq4ysBo cQXGAPFZIAQiSUKeeZp1wcO0sRS2M0nZ1cODXPpbt1xHBzAnKUGM/KWqQ9hAxeBvDYFzqSi1 6/bWIyJpqA4Um5DRz+FhCYho7OZ5Ic2mIBEFFEOvjAxT61jqry94BwzgQIbKCeLNk7oqB0yr rGu4xswepMuQBvlXCuMGgEuCWuiZh2IV+mLwh8ywj18wD3SfGEVBd0ZaJGWzU6kdkdcelxMK 2b+PgZshY3t1YHIDY85w0dvsPPZtfP5+hzqOjCVSieBSMUkwRSY5fcz6fgy1q25U/B+BxXH0 NdiPK7CTQ/Sq5iSGnc94wh9FCdW6V1+u90ADmg7D1d3OVuJDxd8foBgFMBPu5kClSZRlMYty jyGN9E9+JI8ofZkJWEL8vrz8tZtNrbwJdi1HT8OaRJeFPPw7yE0kdVkT+AqFLA0VQCUCv0YA 9R1z2vD2fayt26va5nbwHMtKddwywwnu7/278b9dknKIPF9Soff+MG04A8yJ0Q5xHx86IWiG gqqWlgig1IZDEA2aDUsOieYSm0HLZbXHv6G9XjGVH5Tp2SWlLFbRLyMC/J2Aq2vzpFMzDF+I tigBzNxZJixdgVQWzK73fWCOegce/jQ1AYsJJliHPfsPb3gNvFw6fPT6CRkuLZBgRkODZtRe BJw4YOn1tAGtqvwUYvj0j96FEUq0UCFAwSwElUAUgRKEEQQhUEhRVRUi1BaS0thSxUXqdTC0 vDnUnUzlq0aYnJIb0NsDF2h78KAMiQbygAMnF3zNEvCHEnKdJ5JDhJGkogoClKKJArQr5gOv M9qPY9JydZUuy94ae/tCRazs6emRJPU8LJOzOeQIyJkjyW550p/qhzEI87hSaPZt6oLApO5N hwYZe4E69cEMIpft5s0bkbj0wo7uOAXpy4jRkKck3A7CAX8xXayikhR7ULJQYV1y7YL7r+Qs lP5XjdAdiTfemENm+b55KdiHsnwHQPEY4pXHt4aiUrkendS+EFDWeqAhZEOyrt6q6Q24nDzc eWASS/VTDLjkchN9qbB7ZEeBT4/koCM7E5N5vPk8KXQIE3NBUkqUEZFKlQAlJwQkPzbSSSxo cLgbr07aHIbz8s9QX1Q60j5xiqqlc2Onz92FpXtrKllJ3yUwqcvZvTY4RE/qEfBJvMiwdt/7 2nGu80YQ/73zNzELt9jxSb4PLFA6D24ogLJu2zyWfEF3qAnN0lGL9QMlTRRREpKAaMrEhCPx ffYdHEBnoQekQ7/+rnyBHoj6+Qr6AngFrvRchx4QSIEqss0S1KlIBQoRVRSLaUPm4FHtxO7x R4p6XLRz+/q6Vs7KEoJYqEiKSApYBkifnS5k4kxASwEEbA9Xu9iHZ34pwqbkNlhR1C4SkD4I YXXtqrSqJEJDzztn3KbII8omGdne7y96RtEbu56Yyi0qVKuth5fMCyX7Av0WG/16+B1CiaCE R+HegMJvC13wb3nyMgXjBCVlu2eBw+AMrrMAgQUejQD0m939taES0DWgsWYpsxhlYp7DbJN7 GWbT8/7nLktpH4TLM8NRWh9ejVqTTYkMpZKYt8N5rwxcOaueDxcgznNIvMpeQHI1qQ4xwsst 5lzw5EGnU5hsN7igiIy3seXxtoPATW1VVSpKZxScDMHIJjZZucirNktKFhvHYj9wCc0uB1ei 7U3F0EAMCgPhNbKmwejE2ocFrPCIeyqJaqSG26rCkQM4SJ4Sl2Y8E8uEkUukuc3YB6Ks2TRv mRd99Zd5srYpkKs2eQoZJA4jExN6UTZxs2YA7LgaEKSIO4w4bwMeFYhqQksc4JENgIQ8ueKu ybd2QZoGBU1CSo1A3c94ppETJhtE9JNpHZJsk+bt65z2Tj8I/CSlFFMibgO8KW7IOXnKTPPF Vcd2jn6wuC7pM7BRqMa9WVPHITs09EkKkl43w6YIdUF+SdCEUPN5jpPcR7VnsuefWX27CNbA xRkUlTkTbJPPardN8J4vfOvwIfvFhuRr5hmMMHtnX9blbcJB0OJsaQPtsEA4RDUFonKE2rLp ZXRTaMT+qnngbKSUfEGz05jEh18rek1amEwatC9yaIexT6SEBCmAqbtjMUHlox67ysMPejUG rAqyXZYEQGsy1maT3J2aDbZRmTIuiOI8r5GXsn8HcVUPJZDZpAJCIQ9So0aA+pRcVh8QsMJt Bwm5MQmyOzQr0IZ4hjwKiAXhY5c+QHNoryeGux3lmYQ2l5ZJBhVl5vK+PFnlKw2ScZ8kLhrW 0sIBstqB6wNBxnMqUouYMCGG8gvxE+pBPANgUvKVqbFIDkhQWbKu66Sv5zDN287hZznkLSfq K6DTYYTn0jV7c7nY2B8zOJfRLTwxcQYqFASd0YmobOK0uiEozLlGlo3FbCcMgxcsKchMh1gY D7Fo07wrFyfYHRjok9WY8VYRkISIXhg8aKTYS6OeLECaJN7wDQ7UXDZJ4RnaSTjM+IkjGxTk oyxm4Zec1CP2pMg2yFUG8xOCMTeYSES0i6wZWsyDFxZG9SaqUU37SoNAHHIMdbKJiakGkhIY EkQ0BwalriRzUlAE0EejqfFfFrG2Dgy80UJHPAeZo60xMkAxAwLSjkjQIRIJ1aYp1AqmHnDQ OjHfplsQbopUXAtyEHjZLojqu86yeiWEfG8QJ3gfB3C2LdqVgJyGjrZT+M3glIBnHjDuI3nH Ab0gkiEVg9CAtp6aZKajY1Wm12jq9XENWqUvEmGKwEhLRGEWZSEtCKkvGZphwCAE1DQaWRNK iQaEnjMU1HBC6lEOJQ7WcE6voRh0vdnLTmuTYCp1bEbgmvVIQzXyU0tUQJA66VNLvBxfiOMX Zi75/JNHHyMaDhoOkYvSDcGpiEscPc1y+nxmuOVTqNFupGst5Gp5t924WXrsmTRG+DVk1jC1 5zeojZJ8rSnhnozgd0Sw/Fx96TyHHPs3gHseEOrMBSsqEECS+Q++2l9WWosfJ/UstFrHfE63 0B0R2g+Wok/B4yjrBOLHiiZPu+UOajlCmB9e/3O8bGpCSqvmm0Da953no8r5hQ7SA2dvqKZG NU/TDUwnvjZu8Lm3mIySllKtQsok0wdvuAtAJ8YDMCSBYhYZFNYOMQGESwXvozCgPh69iGQb OzJYCUq4pQTi/ZAihwWKKlkN0WDIQSSkJFTKRDIwaOp4HufGDuD8Px5FNx6DJGRaLKJVUqjn vvW8OOiptQSMEZjdrDFlGU/CWQpgSSJ6l6gJOzeXjRznrB0FWQTj01t8sYFkAhNALw5k4KeP JHlkPfxDD3g6F0ow9oezMPkDY3o4qDrAY593AeocYeEIIQmMS1dqTp5+3BA2gkiPniJ9RGgY GF1z0p0tQZgAskLJ5H6YEi+r3uGcTl424R5gI5nattX2njJSqOfhD66px1xbyxIeuw8pxXV7 UmxM6LPfw6a1HhWyyG36LhZ+nW4YGbpnuO51whfS7KXVAUyEHwgnFN7s0G0o2fdTG9klWIpU pYtbnsz+FVSZHJzVEjYfYQ+aRbyTDKlDAhDMG9RaDlHDwPrWahIt4nygteq+gcQgTceLKIPg 5AOWAYlyzLCobjsEjhmGeB5tRavNqpFdIAWgG0JYLrraUXWMECk9ABc6Oi89BQwSwHRyD3ti yEE5psVSsPtlOn3xnafXM95K89emo8t4sIorZDjUVxjG3eplMDEBGzYIn0R3nHZgeZKoBuCC iZaldq703wPu4NFwqfbC3f281d3UfPHTssL2/a8djSZmyrXwLhVosTbDNRkMlmVhJRVqrApJ HUFAFUZhhiUEFExIQWiMGQ1GVUg9nDi6i8bkWVUAGBiGQLLMPyjoicCQYBC4CEpJgyi/ayRy Atligvmbz46XyfVGkhdojsuC/FsEgeae8CXCFPF3Cbaheq72NjhGy21Bb6YebDSG1bJrCliW ou7FqZxiayYxtNmjGkzIVFhKdcOc/cfMzodnNE6U1bsZH3PCpI8n28I1+wuc7IqYhjuRK/cg i5kuTOt6Gt0vLvV6ivzoKcnhww118fNh9KbRkWp+gqp2DznRaQHIXd5EPSjsLwyN8gjQJ8KC ZJEXasuvDJpcMMkpAB7Kqo4MAgAiToDCQnKEFmaS9lpzJUEy8d9m21ggYFLe9DUdpw8nkajK KatxlStWTNSwPcIuGmZLmIzFzCMLFlueWRrVxCUCQ0IZjdNJAE+n1T9u/xX7uj7RiBo8w+j9 K1h6Y3aHPTXvXvpmdrYhwhGvodhthbYZsbPO7YamshF3ZwWzjrccODaBNDVkOAKwXurQGKJr YWdvCsTh4gbEgsQmly65foFIUhegBJi4RddNqqnZtk/SYZouONCcTJDRWORblrdmqwaQZQTZ wpZSBCTJKrdAEGQjoHSxriy22CNZlNbS2rSzXsnSsLpbSNLODppDNwKUSDp3d3Zk7jC2Q0pQ qdn7JM3ogp2bbWdKvw5Y2DfI6Q6LjMIQkcRMMhQn5VXVNe4Oz1viUzLuV5w9+bNxmt5vkHZm eVooy7wZm8TL1ZrxRetcYvSYFcl7Fgs5Ts+zaXuukhdgbsByc8qxxKRoTE2CoZzp8/0fCP1h 5vVMF8fTUkaAR87XiWYr2NTM7gzrcJlBweMLI2FmlzBiN4HOeNiZwivqhXZ/z8JejjzxiPl8 fa0b8+uPxXyyr5NaYK8HKljEh1bPMWcz04SBFzv2RHomLyAX4yRgxrmu4NxdcgcorigOAPI2 HpuKTAmHzO5rOZhYxxQLLAJCgwpMt+BzIGGWVwG5UcxX7nTwI9Q4I2tCM4hdaxCpUIRNfE4P tlRMu4p4YU8jEK3mYxC8FSwHEd6pBZh5dE+EIP3rlfni5qmNcCB0AmIwE8u9B7bSrkZlFqMo RgenMqd16rRoVzKwW9hrAyHVmoMJFPrcuxeB93PSjFN6XwGTA217hQxTxAMU5xXyJvd7nJYA iUSycY7jniel16YbK0aw9RrzmwPEELmSbziokR+CSrydGS4Gc5DsNG54WvSykHW3U07L5EPD aHhs5mIB07bUzw4rWTSVEqbmwzSxLADuzFl5oRhA+b+FpqowxwkkJ2nSqSzgu2LXpr6BYKEb bBewTYyExoPFRGiKyyZqLMQArDVnz2J1qo9UNqjTR729enrJuY2i8bG88KQOcocMXgvtLQsU /C5wvcPn2uzWWGp7toz1EpzVWWypOtHIgSu1VIKCVIofFs2ASCLsXEnuxhO+1hqzBTmeYA4X EWgc5g4jBrIkzUaayQw7GMA6DGl5szXNQGezao6tSE5dWSRN4FgWjeiOrnvdXaYhFK1OSlZ3 WzMdExcLsGpuwCSEMKjSc1mpBrkyZ2wlsIOw3dp0ZyakDJ5R2kG/DFAvQjJ0KJmkCc/hCxWv Ympm1VsY0qX0NHsknCTc/I5Gcr4ens3JPfrp2o74OZztibpS3XgstRFq1ahVndw6HE7Uh37z Ih1BKURYRTyeTs7j0GjUnaaW3ok0mbUqtCu3Fl7fDZZVpTcU05GaW91uxvGtTnxwcbqXLkma zVmnBUpiNI3uiTZVL9JHoMFc4qhnlLtnJpbodAJihsYNbLDgwY5gOi2qgptGBXvIDZSkSmch EBmWnMUr+jA8YR6toa9mt7F6ggb4JAilBA9UydaUolQ3CR+mxINGjDjiPHgZOgwZTE901o+C RmGJDzMh8gsNMHdPlywcb1MCRIZGGbwDmUiRmLojt4IHZvpaYPXJuVCzH466ArDXS1rI3Lm9 aNWOY5KG8ii1gmhhJTRNrWMahsWxNdDtAfP072CQfKeV5LriMrZILmFTnVL9IqsiJ1OqtBDp A60OLvIRuBq+a0Pz4qhsNy7Q3GY5gJsO170kd9FSJ7/dvTksLXmr4jm9rjdJvI94Zl3Wgkcv PWenjYidqwy8Zp1iPHiE7DcZIuQh1lAFJSdQ2bchJPIIzca+Xv79B9SEUiA6cvPSBDdvI5r3 JEs0p6EZkPUfewdV7F/bJ4jZDk/GE9g1J7X4vhcgqbc0x8z6rB1TZHp9Q97IX7S0UVe1mZmZ 7YcFMfmg9B5vVEb5CAeCSzwQ9cnoq1LS1EMid72VHg/bJ/eJ5NHVJAKA85EPvQT0h5EKTqVX Aqynj8ttQiwbweUCIN9gnEt3zhHkiw8susPPmSQIBIx9VA7YLaSPrhlzm6T+YdR97Q9312MZ JEZDmUZFgRlkEMrC2LzvTwf6e1pvvqJOZH6YsJ8pH2Uo8zJcI5kND72HjJ52DpzlvLIyYvJG UxJaU2e96PkyNa8p9g+pzG6O6xO2V1ON+pbjBvcF9UdcTGFDVI4Q+0u4p2B0+IE5VNR2F3pN XwiF1EWSPI/uYR91RuxS8MqR8CInyQbgyPmCx0x0IHxDAviYBxqkOK4+1OnmcfrAQ74FQaJI kh5YqHoVNChH4yxLZPfWSdkUGioHJD0QzxTn9Neq7ZNtMe6y75Hr2b+/LXqoCAUR5aCrfk2L jQvgoyxDXzcJuA9UjPMb6bLGWOOfInOVYY7Fjlxem2o0XoMem9nPryXR0EpOzoa05gDEo7LD RzFdgzPqXun6x4/EJom4m9BHeewYR0yRN175IKcY7FQLkx4GwfN1goe8eQRDvgZaWNUA23q5 QQ/h5qLQ2+MZKW2ByF7dNDqsq2uWzUtGLm4fJigzSMADSqqxg30kf5JDSuJXzK1ZFzcuaPND 1fgxT0nlp5fAkNAf/xdyRThQkJgw/kQ= --------------070900000900010109070500-- From MAILER-DAEMON Thu Nov 20 19:30:52 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xrc7g-0003b2-0I for mharc-bug-texinfo@gnu.org; Thu, 20 Nov 2014 19:30:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrc7W-0003av-Q7 for bug-texinfo@gnu.org; Thu, 20 Nov 2014 19:30:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xrc7P-0001Uv-3K for bug-texinfo@gnu.org; Thu, 20 Nov 2014 19:30:42 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:46386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrc7O-0001Uf-Ot for bug-texinfo@gnu.org; Thu, 20 Nov 2014 19:30:34 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAKNCVdB015919 for ; Fri, 21 Nov 2014 00:12:45 +0100 Date: Fri, 21 Nov 2014 00:14:55 +0100 From: Patrice Dumas To: bug-texinfo@gnu.org Subject: Re: Orphaned Style Definitions Message-ID: <20141120231455.GC18706@free.fr> Mail-Followup-To: Patrice Dumas , bug-texinfo@gnu.org References: <546D691A.4080706@softwaresam.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546D691A.4080706@softwaresam.us> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 546E755F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:30:50 -0000 On Thu, Nov 20, 2014 at 12:07:54PM +0800, Mahlon wrote: > 20 Nov 2014 > > RE: Orphaned style definitions > > VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64) > > This is not really a bug, just a heads-up: > > There is a block of styles defined in the header of the HTML output. > Two of these styles: > > pre.menu-comment {font-family: serif} > > pre.menu-preformatted {font-family: serif} > > are defined but never invoked. Instead, menus in the HTML are > generated using: > >
... > > which is certainly a better method. > > Clearly, these orphaned style definitions do no harm, and you may > have some idea for using them in the future, but if not, they could > be eliminated from the

Hi Gavin,

I agree that the HTML is straightforward, but here are my specific concerns.

1) In the info output, there is an 'underline' after the header line, but no underline in HTML.

2) HTML compresses whitespace, so line-item columns appear much closer together than in the info output. Unfortunately it is only the line items that are compressed. The header line retains the original spacing which throws off the column alignment between header and line items.

3) Spacing between lines specified in the source does not carry over to the HTML, even if we insert a '@sp 1' into the source. Some tables in the source will specify line spacing and some will not. In the HTML, there is always an extra line in the <dl> sequence and never an extra line in the <table> sequence. Unfortunately, a post-processor has no way of knowing what the source intended because there is no clue in the HTML output.


All of this (except the clairvoyance) is cleanly handled by the provided CSS, and perhaps it's too much work to handle it with generated definitions. Still, someone may eventually get a brilliant idea about how to generate tables that don't need post-processing.

Mahlon









On 11/22/2014 04:05 AM, Gavin Smith wrote:
On Thu, Nov 20, 2014 at 5:20 AM, Mahlon <sam_texinfo@softwaresam.us> wrote:
Without the application of CSS style, the HTML output for both @table and
@multitable could be considered unacceptable for two reasons:

1) the formatting of the HTML output is rather embarrassing, and

2) it doesn't much resemble the 'info' output, neither in line spacing nor
in column spacing

Both of these issues can be corrected with CSS style alone, but you might
consider what could be done inside the texi-to-HTML converter.

I'm not sure if there is a problem here, after all in absence of CSS
the appearance of the page depends on the program (web browser) you
are using to view it.

Both the output for @table and @multitable appear to me to be
straightforward uses of HTML tags expressing the meaning of the
Texinfo source. Are there other tags that could be used instead, or do
you think there should be sensible CSS defaults?

@table output:

<dl compact="compact">
<dt>&lsquo;<samp>for</samp>&rsquo;</dt>
<dt>&lsquo;<samp>while</samp>&rsquo;</dt>
<dd><p>loop while the condition evaluates to &rsquo;true&rsquo;
</p></dd>
<dt>&lsquo;<samp>if</samp>&rsquo;</dt>
<dd><p>execute once if the condition evaluates to &rsquo;true&rsquo;
</p></dd>
</dl>

@multitable output:

<table>
<thead><tr><th>Animal</th><th>Cohort</th><th>Example Sentence</th></tr></thead>
<tr><td>cow</td><td>Placental</td><td>The cow jumped over the fence.</td></tr>
<tr><td>horse</td><td>Placental</td><td>The horse eats flowers and
grass.</td></tr>
<tr><td>wombat</td><td>Marsupial</td><td>The wonderful wombat
can&rsquo;t jump, but seems quite happy!</td></tr>
</table>

--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/

--------------050103050904060305080905-- From MAILER-DAEMON Sat Nov 22 18:20:33 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XsJyj-0006eu-Qg for mharc-bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:20:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsJya-0006Zj-D4 for bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:20:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsJyQ-0000ne-G7 for bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:20:24 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:33772) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsJyQ-0000n8-5X for bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:20:14 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAMNHIFJ029345; Sun, 23 Nov 2014 00:17:31 +0100 Date: Sun, 23 Nov 2014 00:20:00 +0100 From: Patrice Dumas To: Mahlon Subject: Re: HTML Output for @table and @multitable Message-ID: <20141122232000.GB8642@free.fr> Mail-Followup-To: Patrice Dumas , Mahlon , Gavin Smith , Texinfo References: <546D7A27.3090907@softwaresam.us> <5471137D.40407@softwaresam.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5471137D.40407@softwaresam.us> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 5471197E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (saturne.centre-cired.fr [193.51.120.234]); Sun, 23 Nov 2014 00:17:31 +0100 (CET) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:20:31 -0000 Hello, A disclaimer, I don't know CSS at all, so I may be misunderstanding many issues. On Sun, Nov 23, 2014 at 06:51:41AM +0800, Mahlon wrote: > Hi Gavin, > > I agree that the HTML is straightforward, but here are my specific concerns. > > 1) In the info output, there is an 'underline' after the header > line, but no underline in HTML. That's not really an issue. In Info there is no possibility of bold nor change in font size, so the underline is the only way to mark a header, but in HTML and TeX, there are other ways, in my opinion better ways to mark a header. The formatting need not be exactly the same, what is important is that reader connect the 2 formatting, and do not see different logical organization when looking at HTML, Info or pdf output. > 2) HTML compresses whitespace, so line-item columns appear much > closer together than in the info output. Unfortunately it is _only_ > the line items that are compressed. The header line retains the > original spacing which throws off the column alignment between > header and line items. I don't get it at all... > 3) Spacing between lines specified in the source does not carry over > to the HTML, even if we insert a '@sp 1' into the source. Normally, @sp 1 becomes one
, so it should appear? > Some > tables in the source will specify line spacing and some will not. In > the HTML, there is _always_an extra line in the
sequence and > _never_an extra line in the sequence. Unfortunately, a > post-processor has no way of knowing what the source intended > because there is no clue in the HTML output. I don't get it. Why is there always an extra line in the
sequence? And why never in the
sequence? We use rather simple HTML markup as intended, maybe with some styling, but, in most case it is just plain HTML markup. > All of this (except the clairvoyance) is cleanly handled by the > provided CSS, and perhaps it's too much work to handle it with > generated definitions. Still, someone may eventually get a brilliant > idea about how to generate tables that don't need post-processing. Post-processing for what? In any case, there is something that is certainly sub-optimal, it is the @itemize with anything else than @bullet, as we remove the bullet from
  • and then add a symbol in the text. I have no idea how to do something better, though, opinions welcome. -- Pat From MAILER-DAEMON Sat Nov 22 18:25:21 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XsK3N-0004Dw-T2 for mharc-bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:25:21 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsK3D-0004DE-Qz for bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:25:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsK36-0002pP-0k for bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:25:11 -0500 Received: from saturne.centre-cired.fr ([193.51.120.234]:37375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsK35-0002oD-OT for bug-texinfo@gnu.org; Sat, 22 Nov 2014 18:25:03 -0500 Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sAMNM6dO029423; Sun, 23 Nov 2014 00:22:06 +0100 Date: Sun, 23 Nov 2014 00:24:48 +0100 From: Patrice Dumas To: Karl Berry Subject: Re: HTML conversion should ignore 'exdent' command Message-ID: <20141122232448.GC8642@free.fr> Mail-Followup-To: Patrice Dumas , Karl Berry , sam_texinfo@softwaresam.us, bug-texinfo@gnu.org References: <5466F204.60505@softwaresam.us> <201411152348.sAFNmqOw021339@freefriends.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411152348.sAFNmqOw021339@freefriends.org> User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 54711A9E.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (saturne.centre-cired.fr [193.51.120.234]); Sun, 23 Nov 2014 00:22:19 +0100 (CET) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 23:25:19 -0000 On Sat, Nov 15, 2014 at 11:48:52PM +0000, Karl Berry wrote: > Patrice, > > 1. Can CSS be used to accomplish the exdenting? Extra blank lines seem > troublesome. Ignoring @exdent doesn't sound right either. I do not know enough about CSS to answer that (in fact I known almost nothing about CSS, besides the syntax). In particular, I do not know if it is possible to use style to avoid extra blank lines with
    , nor
    what CSS triggers exdenting.
    
    > 2. In TeX, the exdented text is printed in roman.  I don't know if
    > HTML/CSS has a way to say "go back to the main font" (which might be
    > either serif or sans-serif in the HTML world) these days.  It didn't use
    > to.  Anyway, it would be nice if it could happen, but using either
    > span.roman or span.sansserif specifically doesn't seem right.
    
    That should be easier, however, as we already use 
      "font-family: inherit;"
    for the @display and @format that are similarly in 
     but should not
    be in monospace font.
    
    -- 
    Pat
    
    
    From MAILER-DAEMON Sat Nov 22 19:14:53 2014
    Received: from list by lists.gnu.org with archive (Exim 4.71)
    	id 1XsKpJ-00036p-38
    	for mharc-bug-texinfo@gnu.org; Sat, 22 Nov 2014 19:14:53 -0500
    Received: from eggs.gnu.org ([2001:4830:134:3::10]:34182)
    	by lists.gnu.org with esmtp (Exim 4.71)
    	(envelope-from ) id 1XsKpB-000363-Kl
    	for bug-texinfo@gnu.org; Sat, 22 Nov 2014 19:14:51 -0500
    Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
    	(envelope-from ) id 1XsKp5-0005iS-GC
    	for bug-texinfo@gnu.org; Sat, 22 Nov 2014 19:14:45 -0500
    Received: from frenzy.freefriends.org ([66.54.153.139]:42396
    	helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71)
    	(envelope-from ) id 1XsKp5-0005iM-9P
    	for bug-texinfo@gnu.org; Sat, 22 Nov 2014 19:14:39 -0500
    X-Envelope-From: karl@freefriends.org
    Received: from freefriends.org (localhost [127.0.0.1])
    	by freefriends.org (8.14.9/8.14.9) with ESMTP id sAN0EcRV017751;
    	Sat, 22 Nov 2014 17:14:38 -0700
    Received: (from nobody@localhost)
    	by freefriends.org (8.14.9/8.14.9/submit) id sAN0EbAf017749;
    	Sun, 23 Nov 2014 00:14:37 GMT
    Date: Sun, 23 Nov 2014 00:14:37 GMT
    Message-Id: <201411230014.sAN0EbAf017749@freefriends.org>
    X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to
    	karl@freefriends.org using -f
    From: karl@freefriends.org (Karl Berry)
    To: sam_texinfo@softwaresam.us, bug-texinfo@gnu.org
    Subject: Re: HTML Output for @table and @multitable
    In-Reply-To: <20141122232000.GB8642@free.fr>
    X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
    X-Received-From: 66.54.153.139
    X-BeenThere: bug-texinfo@gnu.org
    X-Mailman-Version: 2.1.14
    Precedence: list
    List-Id: Bug reports for the GNU Texinfo documentation system
    	
    List-Unsubscribe: ,
    	
    List-Archive: 
    List-Post: 
    List-Help: 
    List-Subscribe: ,
    	
    X-List-Received-Date: Sun, 23 Nov 2014 00:14:52 -0000
    
        Normally, @sp 1 becomes one 
    , so it should appear? Inside
  • , I think it would have to be a blank row ( or some such). I'm not sure if it's desirable. > Some tables in the source will specify line spacing and some will not. Texinfo has never been about precisely specifying the appearance of the output. (If you want that, use TeX.) It's about logical input. Why is there always an extra line in the
    sequence? Because browsers (stupidly IMHO) render the
    on a line by itself, separate from the
    . We could always put the @table's @item on the same line as the description by using
     
    instead of
    , but it's not clear to me that is better. I don't know of any decent way to replicate the TeX (and Info, I think) output of @table in HTML, namely if the item name is short enough, put it on a line by itself, if not, put it on its own line. K From MAILER-DAEMON Sun Nov 23 05:12:55 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XsUA3-00027B-6C for mharc-bug-texinfo@gnu.org; Sun, 23 Nov 2014 05:12:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsU9t-00026f-Co for bug-texinfo@gnu.org; Sun, 23 Nov 2014 05:12:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsU9m-00020d-8f for bug-texinfo@gnu.org; Sun, 23 Nov 2014 05:12:45 -0500 Received: from p3nlsmtpcp01-01.prod.phx3.secureserver.net ([184.168.200.138]:54912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsU9l-00020N-UP for bug-texinfo@gnu.org; Sun, 23 Nov 2014 05:12:38 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-01.prod.phx3.secureserver.net with : CPANEL : id JyAN1p01U2RsmEA01yAN5C; Sun, 23 Nov 2014 03:10:25 -0700 Received: from [124.207.38.54] (port=39923 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XsU9e-0002oC-5J; Sun, 23 Nov 2014 03:12:30 -0700 Message-ID: <5471B2F1.6070609@softwaresam.us> Date: Sun, 23 Nov 2014 18:12:01 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Patrice Dumas , Gavin Smith , Texinfo Subject: HTML Output for @table and @multitable and misc. References: <546D7A27.3090907@softwaresam.us> <5471137D.40407@softwaresam.us> <20141122232000.GB8642@free.fr> In-Reply-To: <20141122232000.GB8642@free.fr> Content-Type: multipart/alternative; boundary="------------090608070404040408050808" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.138 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 10:12:53 -0000 This is a multi-part message in MIME format. --------------090608070404040408050808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Pat, On the issue of separating the header line from the table contents, I agree that it is a minor issue. Inside a
    sequence, the header
    is bold by default, so it is visually distinct from the non-bold line items. The issue of compressed whitespace is a problem without the CSS. For example, (I'll show this in monospace for clarity). What aligns nicely in the info output: State Capital Flower --------------------------------------------- Georgia Atlanta Azalea California Sacramento California Poppy Delaware Dover Peach blossom Looks like this in unstyled HTML: *State Capital Flower* Georgia Atlanta Azalea California Sacramento California Poppy Delaware Dover Peach blossom Note that the whitespace in the header is retained, while the whitespace in the line items is compressed, which causes vertical misalignment. This is where the post-processing comes into play. /Normally, @sp 1 becomes one
    , so it should appear?/ You're right, that is my mistake. /I don't get it. Why is there always an extra line in the
    sequence?/ /And why never in the sequence? We use rather simple HTML markup / /as intended, maybe with some styling, but, in most case it is just plain/ /HTML markup./ For the @table command, this is just a regrettable issue with the default definition of the
    sequence not matching the info output. Again, it can be solved using CSS, so it's nothing to worry about. It's just that casual users of the HTML won't know enough CSS to fix it, so if you have no objection to recommending my CSS definitions, it could save a lot of weekend warriors from styling headaches. For the @multitable, line spacing isn't much of an issue because the default looks pretty good although a bit different from the info output. /In any case, there is something that is certainly sub-optimal, it is the/ /@itemize with anything else than @bullet, as we remove the bullet from/ /
  • and then add a symbol in the text. I have no idea how to do/ /something better, though, opinions welcome./ Finally, the issues with @itemize bullets and @enumerate types other that 1, 2, 3... are a problem I'm still working on. I'm experimenting with a post-processor that will scan for the embedded bullets that follow the
      . I'll let you know if I get any lightbulbs on that one. Because @enumerate uses only the default
        ...
      sequence, any enumeration types specified in the texi source are ignored. _I think it's important to directly support at least the following in the converter_: @enumerate (default
        is ok) @enumerate 1 (default
          is ok) @enumerate A (
            ) @enumerate a (
              ) Note that
                and
                  are deprecated constructs in HTML4 and are no longer supported in HTML5, although browsers may continue to support them. To sum up, if you want to recommend my CSS style file, it should minimize problems for many HTML documenters, and we can consider the other issues for the next major release. Because I'm a teacher, I get a month off in January, so please let me know if I can help with anything. :-) Mahlon On 11/23/2014 07:20 AM, Patrice Dumas wrote: > Hello, > > A disclaimer, I don't know CSS at all, so I may be misunderstanding many > issues. > > > On Sun, Nov 23, 2014 at 06:51:41AM +0800, Mahlon wrote: >> Hi Gavin, >> >> I agree that the HTML is straightforward, but here are my specific concerns. >> >> 1) In the info output, there is an 'underline' after the header >> line, but no underline in HTML. > That's not really an issue. In Info there is no possibility of bold nor > change in font size, so the underline is the only way to mark a header, > but in HTML and TeX, there are other ways, in my opinion better ways to > mark a header. The formatting need not be exactly the same, what is > important is that reader connect the 2 formatting, and do not see > different logical organization when looking at HTML, Info or pdf output. > >> 2) HTML compresses whitespace, so line-item columns appear much >> closer together than in the info output. Unfortunately it is _only_ >> the line items that are compressed. The header line retains the >> original spacing which throws off the column alignment between >> header and line items. > I don't get it at all... > >> 3) Spacing between lines specified in the source does not carry over >> to the HTML, even if we insert a '@sp 1' into the source. > Normally, @sp 1 becomes one
                  , so it should appear? > >> Some >> tables in the source will specify line spacing and some will not. In >> the HTML, there is _always_an extra line in the
                  sequence and >> _never_an extra line in the
  • sequence. Unfortunately, a >> post-processor has no way of knowing what the source intended >> because there is no clue in the HTML output. > I don't get it. Why is there always an extra line in the
    sequence? > And why never in the
    sequence? We use rather simple HTML markup > as intended, maybe with some styling, but, in most case it is just plain > HTML markup. > >> All of this (except the clairvoyance) is cleanly handled by the >> provided CSS, and perhaps it's too much work to handle it with >> generated definitions. Still, someone may eventually get a brilliant >> idea about how to generate tables that don't need post-processing. > Post-processing for what? > > > In any case, there is something that is certainly sub-optimal, it is the > @itemize with anything else than @bullet, as we remove the bullet from >
  • and then add a symbol in the text. I have no idea how to do > something better, though, opinions welcome. > -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------090608070404040408050808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Pat,

    On the issue of separating the header line from the table contents, I agree that it is a minor issue. Inside a <table> sequence, the header <th> is bold by default, so it is visually distinct from the non-bold <tl> line items.

    The issue of compressed whitespace is a problem without the CSS. For example, (I'll show this in monospace for clarity). What aligns nicely in the info output:

    State         Capital        Flower

    ---------------------------------------------

    Georgia       Atlanta        Azalea

    California    Sacramento     California Poppy

    Delaware      Dover          Peach blossom



    Looks like this in unstyled HTML:


    State         Capital        Flower

    Georgia    Atlanta    Azalea

    California Sacramento California Poppy

    Delaware   Dover      Peach blossom


    Note that the whitespace in the header is retained, while the whitespace in the line items is compressed, which causes vertical misalignment. This is where the post-processing comes into play.


    Normally, @sp 1 becomes one <br>, so it should appear?

    You're right, that is my mistake.


    I don't get it. Why is there always an extra line in the <dl> sequence?

    And why never in the <table> sequence? We use rather simple HTML markup

    as intended, maybe with some styling, but, in most case it is just plain

    HTML markup.

    For the @table command, this is just a regrettable issue with the default definition of the <dl> sequence not matching the info output. Again, it can be solved using CSS, so it's nothing to worry about. It's just that casual users of the HTML won't know enough CSS to fix it, so if you have no objection to recommending my CSS definitions, it could save a lot of weekend warriors from styling headaches. For the @multitable, line spacing isn't much of an issue because the default looks pretty good although a bit different from the info output.


    In any case, there is something that is certainly sub-optimal, it is the

    @itemize with anything else than @bullet, as we remove the bullet from

    <li> and then add a symbol in the text. I have no idea how to do

    something better, though, opinions welcome.

    Finally, the issues with @itemize bullets and @enumerate types other that 1, 2, 3... are a problem I'm still working on.

    I'm experimenting with a post-processor that will scan for the embedded bullets that follow the <ul class=“no-bullet”>. I'll let you know if I get any lightbulbs on that one.

    Because @enumerate uses only the default <ol> ... </ol> sequence, any enumeration types specified in the texi source are ignored. I think it's important to directly support at least the following in the converter:

    @enumerate (default <ol> is ok)

    @enumerate 1 (default <ol> is ok)

    @enumerate A ( <ol style=“list-style-type:upper-alpha;”> )

    @enumerate a ( <ol style=“list-style-type:lower-alpha;”> )

    Note that <ul type=...> and <ol type=...> are deprecated constructs in HTML4 and are no longer supported in HTML5, although browsers may continue to support them.


    To sum up, if you want to recommend my CSS style file, it should minimize problems for many HTML documenters, and we can consider the other issues for the next major release.

    Because I'm a teacher, I get a month off in January, so please let me know if I can help with anything. :-)

    Mahlon









    On 11/23/2014 07:20 AM, Patrice Dumas wrote:
    Hello,
    
    A disclaimer, I don't know CSS at all, so I may be misunderstanding many
    issues.
    
    
    On Sun, Nov 23, 2014 at 06:51:41AM +0800, Mahlon wrote:
    
    Hi Gavin,
    
    I agree that the HTML is straightforward, but here are my specific concerns.
    
    1) In the info output, there is an 'underline' after the header
    line, but no underline in HTML.
    
    That's not really an issue.  In Info there is no possibility of bold nor
    change in font size, so the underline is the only way to mark a header,
    but in HTML and TeX, there are other ways, in my opinion better ways to
    mark a header.  The formatting need not be exactly the same, what is
    important is that reader connect the 2 formatting, and do not see
    different logical organization when looking at HTML, Info or pdf output.
    
    
    2) HTML compresses whitespace, so line-item columns appear much
    closer together than in the info output. Unfortunately it is _only_
    the line items that are compressed. The header line retains the
    original spacing which throws off the column alignment between
    header and line items.
    
    I don't get it at all...
    
    
    3) Spacing between lines specified in the source does not carry over
    to the HTML, even if we insert a '@sp 1' into the source. 
    
    Normally, @sp 1 becomes one <br>, so it should appear?
    
    
    Some
    tables in the source will specify line spacing and some will not. In
    the HTML, there is _always_an extra line in the <dl> sequence and
    _never_an extra line in the <table> sequence. Unfortunately, a
    post-processor has no way of knowing what the source intended
    because there is no clue in the HTML output.
    
    I don't get it.  Why is there always an extra line in the <dl> sequence?
    And why never in the <table> sequence?  We use rather simple HTML markup 
    as intended, maybe with some styling, but, in most case it is just plain
    HTML markup.
    
    
    All of this (except the clairvoyance) is cleanly handled by the
    provided CSS, and perhaps it's too much work to handle it with
    generated definitions. Still, someone may eventually get a brilliant
    idea about how to generate tables that don't need post-processing.
    
    Post-processing for what?
    
    
    In any case, there is something that is certainly sub-optimal, it is the
    @itemize with anything else than @bullet, as we remove the bullet from
    <li> and then add a symbol in the text.  I have no idea how to do
    something better, though, opinions welcome.
    
    

    --

    Software Sam - software and tools for GNU/Linux

    Mahlon Smith,
    The Software Samurai
    On the Web: http://www.SoftwareSam.us/

    --------------090608070404040408050808-- From MAILER-DAEMON Sun Nov 23 07:48:37 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XsWaj-00040a-OY for mharc-bug-texinfo@gnu.org; Sun, 23 Nov 2014 07:48:37 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsWab-00040Q-QG for bug-texinfo@gnu.org; Sun, 23 Nov 2014 07:48:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsWaU-0005kU-M7 for bug-texinfo@gnu.org; Sun, 23 Nov 2014 07:48:29 -0500 Received: from p3nlsmtpcp01-01.prod.phx3.secureserver.net ([184.168.200.138]:39919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsWaU-0005jm-ES for bug-texinfo@gnu.org; Sun, 23 Nov 2014 07:48:22 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-01.prod.phx3.secureserver.net with : CPANEL : id K0mD1p00Q2RsmEA010mDZy; Sun, 23 Nov 2014 05:46:13 -0700 Received: from [124.207.38.54] (port=39968 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XsWaQ-0000un-NP; Sun, 23 Nov 2014 05:48:21 -0700 Message-ID: <5471D775.4060800@softwaresam.us> Date: Sun, 23 Nov 2014 20:47:49 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Patrice Dumas Subject: HTML and 'exdent' command (continued) References: <5466F204.60505@softwaresam.us> <20141115112943.GA26753@free.fr> <54695CBF.5040906@softwaresam.us> <20141122230524.GA8642@free.fr> In-Reply-To: <20141122230524.GA8642@free.fr> Content-Type: multipart/alternative; boundary="------------090108040005030604010703" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.138 Cc: Texinfo X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 12:48:37 -0000 This is a multi-part message in MIME format. --------------090108040005030604010703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Pat, The 'exdent' is difficult to style, but not impossible. * The @exdent would apply _only_ inside @example and @display blocks because these blocks arepreformatted AND indented. @exdent should be ignored everywhere else. * Note that currently, @exdent is also recognized inside @indentedblock and @quotation blocks; however, these are not preformatted, so the @exdent messes up the word-wrap algorithm. * Of course @exdent has no effect inside @format and @verbatim blocks because they are not indented. * Because I don't see it being used regularly by anyone even in the info output, it's probably not worth much time; however, the trick to get an HTML exdented line is: 1) define the 'example' class as having flush-left margins: margin-left: 0; 2) define 'example'
     as: margin-left: 3.2em;
    
    3) define the exdented line _only_ as outside of the 
     i.e. as 
    top-level 'example' text.
    
    4) Even though the 'example' class itself is defined with 'white-space: 
    pre', to make this work, we must continue to have a 
     tag designed 
    in CSS specifically for the 'example' and 'display' classes to 
    differentiate between standard and exdented text.
    
    
    Here is an @example block as generated by the converter:
    
    
    unmodified line
    
    
    exdented line
    
    
    unmodified line
    
    
    And here is one that looks /reasonably/ good after style definitions have been applied:
    unmodified line
    
    
    exdented line
    unmodified line
    
    
    Here is the CSS test definition for @example. @display would be similar, but not monospace. .example { font-family: monospace; font-size: inherit; font-style: inherit; font-weight: inherit; color: inherit; white-space: pre; margin-left: 0; } .example pre { font-family: inherit; font-size: inherit; font-style: inherit; font-weight: inherit; color: inherit; white-space: inherit; margin-left: 3.2em; } There are certainly other ways to do it, and some of them would not generate the blank line before and after the exdented line, but this seems to be the easiest to implement in the converter. If you think it's worth some effort, I will continue experimenting with it. Mahlon On 11/23/2014 07:05 AM, Patrice Dumas wrote: > On Mon, Nov 17, 2014 at 10:26:07AM +0800, Mahlon wrote: >> Hello all, >> >> Yes, it can be done in CSS, and in fact I'm writing a reasonably >> comprehensive CSS definition file that can be applied to the >> texi-to-HTML output. >> >> http://www.softwaresam.us/docs/docs.html > Ok. If I understand well, you would like some integration of that in > makeinfo. In any case, we can redistribute your css file in the contrib > directory. > >> The reason I bring it up is that the exdent looks bad any way I try >> it. > But is there a way to make it look good? Does it look good if in a > and not a
    ?  Or is it necessarily incorporated within a main
    > 
     instead of having it split in 3?
    >
    
    -- 
    
    Software Sam - software and tools for GNU/Linux
    
    Mahlon Smith,
    /The Software Samurai/
    On the Web: /http://www.SoftwareSam.us/ 
    /
    
    
    --------------090108040005030604010703
    Content-Type: text/html; charset=utf-8
    Content-Transfer-Encoding: 7bit
    
    
      
        
      
      
        
        

    Hi Pat,

    The 'exdent' is difficult to style, but not impossible.

    • The @exdent would apply only inside @example and @display blocks because these blocks are preformatted AND indented. @exdent should be ignored everywhere else.

    • Note that currently, @exdent is also recognized inside @indentedblock and @quotation blocks; however, these are not preformatted, so the @exdent messes up the word-wrap algorithm.

    • Of course @exdent has no effect inside @format and @verbatim blocks because they are not indented.

    • Because I don't see it being used regularly by anyone even in the info output, it's probably not worth much time; however, the trick to get an HTML exdented line is:

    1) define the 'example' class as having flush-left margins: margin-left: 0;

    2) define 'example' <pre> as: margin-left: 3.2em;

    3) define the exdented line only as outside of the <pre> i.e. as top-level 'example' text.

    4) Even though the 'example' class itself is defined with 'white-space: pre', to make this work, we must continue to have a <pre> tag designed in CSS specifically for the 'example' and 'display' classes to differentiate between standard and exdented text.


    Here is an @example block as generated by the converter:

    <div class="example">

    <pre class="example">unmodified line

    </pre><pre class="example">exdented line

    </pre><pre class="example">unmodified line

    </pre></div>

    And here is one that looks reasonably good after style definitions have been applied:

    <div class="example">

    <pre>unmodified line

    </pre>exdented line

    <pre>unmodified line

    </pre></div>


    Here is the CSS test definition for @example. @display would be similar, but not monospace.

    .example

    {

    font-family: monospace;

    font-size: inherit;

    font-style: inherit;

    font-weight: inherit;

    color: inherit;

    white-space: pre;

    margin-left: 0;

    }

    .example pre

    {

    font-family: inherit;

    font-size: inherit;

    font-style: inherit;

    font-weight: inherit;

    color: inherit;

    white-space: inherit;

    margin-left: 3.2em;

    }

    There are certainly other ways to do it, and some of them would not generate the blank line before and after the exdented line, but this seems to be the easiest to implement in the converter. If you think it's worth some effort, I will continue experimenting with it.

    Mahlon



    On 11/23/2014 07:05 AM, Patrice Dumas wrote:
    On Mon, Nov 17, 2014 at 10:26:07AM +0800, Mahlon wrote:
    
    Hello all,
    
    Yes, it can be done in CSS, and in fact I'm writing a reasonably
    comprehensive CSS definition file that can be applied to the
    texi-to-HTML output.
    
    http://www.softwaresam.us/docs/docs.html
    
    Ok.  If I understand well, you would like some integration of that in
    makeinfo.  In any case, we can redistribute your css file in the contrib
    directory.
    
    
    The reason I bring it up is that the exdent looks bad any way I try
    it.
    
    But is there a way to make it look good?  Does it look good if in a
    <span> and not a <pre>?  Or is it necessarily incorporated within a main
    <pre> instead of having it split in 3?
    
    

    --

    Software Sam - software and tools for GNU/Linux

    Mahlon Smith,
    The Software Samurai
    On the Web: http://www.SoftwareSam.us/

    --------------090108040005030604010703-- From MAILER-DAEMON Sun Nov 23 11:58:14 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XsaUI-0007pI-OV for mharc-bug-texinfo@gnu.org; Sun, 23 Nov 2014 11:58:14 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsaUA-0007ea-KX for bug-texinfo@gnu.org; Sun, 23 Nov 2014 11:58:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsaU3-0006HH-Q5 for bug-texinfo@gnu.org; Sun, 23 Nov 2014 11:58:06 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:48708 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsaU3-0006Gv-Ji for bug-texinfo@gnu.org; Sun, 23 Nov 2014 11:57:59 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sANGvtr0016654; Sun, 23 Nov 2014 09:57:55 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sANGvtb7016652; Sun, 23 Nov 2014 16:57:55 GMT Date: Sun, 23 Nov 2014 16:57:55 GMT Message-Id: <201411231657.sANGvtb7016652@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: per@bothner.com, bug-texinfo@gnu.org Subject: Re: real subscripts and superscripts? In-Reply-To: <20141122183300.GC30101@free.fr> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 16:58:12 -0000 > I can add these to texinfo.tex and texinfo.texi, etc., easily enough. > Do you have time to add it to makeinfo? Yes. Great. I will work on it next week. For HTML cross manual I propose doing the same as for "style" commands and key and kbd, that is replace by the content. Agreed. Also in raw text, I propose using content as is without any formatting (used for instance for file names, for index sorting). Fine. Thanks, K From MAILER-DAEMON Thu Nov 27 02:56:44 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XttwS-0002Os-P5 for mharc-bug-texinfo@gnu.org; Thu, 27 Nov 2014 02:56:44 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XttwJ-0002Es-Hr for bug-texinfo@gnu.org; Thu, 27 Nov 2014 02:56:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XttUp-0005Og-3r for bug-texinfo@gnu.org; Thu, 27 Nov 2014 02:29:17 -0500 Received: from p3nlsmtpcp01-02.prod.phx3.secureserver.net ([184.168.200.140]:52708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XttUo-0005Lt-KE for bug-texinfo@gnu.org; Thu, 27 Nov 2014 02:28:10 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-02.prod.phx3.secureserver.net with : CPANEL : id LXR71p0012RsmEA01XR73Y; Thu, 27 Nov 2014 00:25:10 -0700 Received: from [124.207.38.54] (port=55672 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XttUh-0007rZ-SM for bug-texinfo@gnu.org; Thu, 27 Nov 2014 00:28:04 -0700 Message-ID: <5476D27E.3020308@softwaresam.us> Date: Thu, 27 Nov 2014 15:27:58 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Texinfo Subject: @itemize and @enumerate enhancements Content-Type: multipart/alternative; boundary="------------070305040705060207080307" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.140 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 07:56:42 -0000 This is a multi-part message in MIME format. --------------070305040705060207080307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 27 Nov 2014 RE: HTML output for @itemize and @enumerate commands VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64) BUG: It is not certain whether these are bugs or an enhancement request, so you decide. Following up on the previous discussion. The HTML output for both @itemize and @enumerate are rudimentary. Not only is some of the TexInfo source formatting lost, the generated markup does not take advantage of the available HTML constructs. These problems are deep, and not easy to address: @itemize (
      ) 1. @itemize correctly takes advantage of the HTML defaults for: @itemize (no argument) @itemize @bullet 2. For arguments other than @bullet, the generated HTML looks like:
      • ...
      • ...
          o First, this means that so long as the no-bullet class is defined, the browser will render the list without bullets. o Second, the bullet character (whatever was specified in the source) is embedded inside the line item. _I fully understand this design decision_, and I probably would have done it the same way if I were in a hurry. o Third, because the bullet character is embedded in the line item, second and subsequent lines of the item appear to be vertically mis-aligned. 3. For '@itemize @minus' lists, the info output uses the Unicode minus (U+2212) for the bullet, while the HTML inserts a plain minus sign '-' (U+002D). I think it would be better to be consistent and output: − 4. For '@itemize @w{}' lists, the 'info' output generates a space character where the bullet would have been and does not generate an extra embedded space. This seems to be the correct implementation. 5. *Enhancement Possibility* I feel that full support for the HTML bullet types: [disc | circle | square | none] is both necessary and convenient. We could either hard-code a style in the converter, OR reference a class definition for each type. In order to maintain flexibility and to be consistent with the current converter design, I recommend the class callout. The actual names for the new classes are up to you, but the following are the names used in the current version of the CSS definition file. Parsing logic (most likely first): * if ( argument == none || argument == @bullet ) generate:
            ...
          OR
            ...
          (note: the default bullet type is 'disc') * else if ( argument == @w{} || (TABLE OF CONTENTS) ) generate:
            ...
          * else if ( argument == @textdegree || argument == @BCIRCLE(U+26AC) ) generate:
            ...
          * else generate:
            ...
          (note: for bullet characters not supported by HTML, default to the third type of HTML bullet) 6. Note that if you decide to hard-code the bullet style, you should use:
            because the
              construct is deprecated in HTML4 and not supported by HTML5. @enumerate (
                ) 1. '@enumerate' correctly takes advantage of the HTML defaults for decimal (1, 2, 3, ...) @enumerate (no argument) @enumerate 1 2. For non-decimal enumerators, the enumerator specified in the source is lost. 3. HTML supports several enumeration types, but not all of them have TexInfo equivalents. 4. I think it's important to directly support at least the following in the converter: * @enumerate (default
                  is ok) * @enumerate 1 (default
                    is ok) * @enumerate A class callout:
                      hard-coded:
                        * @enumerate a class callout:
                          hard-coded:
                            5. Additional enumeration types that would be desirable: * lower-case Roman numerals, class callout:
                              hard-coded:
                                * upper-case Roman numerals, class callout:
                                  hard-coded:
                                    * lower-case Greek letters class callout:
                                      hard-coded:
                                        6. My idea for supporting additional enumeration types in info and HTML output would look like this: @enumerate @xxx{n} where 'xxx' is the name of the enumeration type, and the _optional_'n' would specify the starting value. HTML expects a decimal start for all types i.e.
                                          OR
                                            (for starting mid-sequence) * Even though HTML5 (according to w3.org) brings back the
                                              syntax, it's better to consistently use the style's actual name. 10. Parsing logic (most likely first) * if ( argument == (DECIMAL NUMBER) || argument == (NONE) ) info: 1, 2, 3, 4, 5, ... (or start at specified point) HTML:
                                                ...
                                              * else if ( argument >= 'a' && argument <= 'z' || argument == @loweralpha ) info: 'a'-'z' as currently implemented, @loweralpha as if it were 'a', or @loweralpha{n} where 'n' is the start point HTML:
                                                ...
                                              * else if ( argument >= 'A' && argument <= 'Z' || @upperalpha ) info: 'A'-'Z' as currently implemented, @upperalpha as if it were 'A' or @upperalpha{n} where 'n' is the start point HTML:
                                                ...
                                              * if ( argument == @lowerroman ) info: i, ii, iii, iv, v, ... or @lowerroman{n} where 'n' is the start point HTML:
                                                ...
                                              * else if ( argument == @upperroman ) info: I, II, III, IV, V, ... or @upperroman{n} where 'n' is the start point HTML:
                                                ...
                                              * else if ( argument == @lowergreek ) info: α, β, γ, δ, ε, ... or @lowergreek{n} where 'n' is the start point HTML:
                                                ...
                                              * else // (default to decimal) info: 1, 2, 3, 4, 5, ... HTML:
                                                ...
                                              All of the above is of course just suggestion, but some of it seems necessary and/or highly desirable for the future of @itemize and @enumerate lists. PS: I will post an updated version of the CSS definition file to my website this weekend. Cheers, Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------070305040705060207080307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

                                              27 Nov 2014

                                              RE: HTML output for @itemize and @enumerate commands

                                              VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

                                              BUG: It is not certain whether these are bugs or an enhancement request, so you decide.

                                              Following up on the previous discussion.



                                              The HTML output for both @itemize and @enumerate are rudimentary. Not only is some of the TexInfo source formatting lost, the generated markup does not take advantage of the available HTML constructs.

                                              These problems are deep, and not easy to address:

                                              @itemize (<ul>)

                                              1. @itemize correctly takes advantage of the HTML defaults for:
                                                @itemize (no argument)
                                                @itemize @bullet

                                              2. For arguments other than @bullet, the generated HTML looks like:
                                                <ul class=”no-bullet”><li> ... </li> ... <ul>

                                                • First, this means that so long as the no-bullet class is defined, the browser will render the list without bullets.

                                                • Second, the bullet character (whatever was specified in the source) is embedded inside the line item. I fully understand this design decision, and I probably would have done it the same way if I were in a hurry.

                                                • Third, because the bullet character is embedded in the line item, second and subsequent lines of the item appear to be vertically mis-aligned.

                                              1. For '@itemize @minus' lists, the info output uses the Unicode minus (U+2212) for the bullet, while the HTML inserts a plain minus sign '-' (U+002D). I think it would be better to be consistent and output: &#x2212;

                                              2. For '@itemize @w{}' lists, the 'info' output generates a space character where the bullet would have been and does not generate an extra embedded space. This seems to be the correct implementation.

                                              3. Enhancement Possibility
                                                I feel that full support for the HTML bullet types: [disc | circle | square | none] is both necessary and convenient. We could either hard-code a style in the converter, OR reference a class definition for each type. In order to maintain flexibility and to be consistent with the current converter design, I recommend the class callout. The actual names for the new classes are up to you, but the following are the names used in the current version of the CSS definition file. Parsing logic (most likely first):

                                                • if ( argument == none || argument == @bullet )
                                                  generate: <ul class="disc-bullet"> ... </ul> OR <ul> ... </ul>
                                                  (note: the default bullet type is 'disc')

                                                • else if ( argument == @w{} || (TABLE OF CONTENTS) )
                                                  generate: <ul class="no-bullet"> ... </ul>

                                                • else if ( argument == @textdegree || argument == @BCIRCLE(U+26AC) )
                                                  generate: <ul class="circle-bullet"> ... </ul>

                                                • else
                                                  generate: <ul class="square-bullet"> ... </ul>
                                                  (note: for bullet characters not supported by HTML,
                                                  default to the third type of HTML bullet)

                                              4. Note that if you decide to hard-code the bullet style, you should use:
                                                <ul style=“list-style-type:xxx;”> because the <ul type=”xxx”> construct is deprecated in HTML4 and not supported by HTML5.



                                              @enumerate (<ol>)

                                              1. '@enumerate' correctly takes advantage of the HTML defaults for decimal (1, 2, 3, ...)
                                                @enumerate (no argument)
                                                @enumerate 1

                                              2. For non-decimal enumerators, the enumerator specified in the source is lost.

                                              3. HTML supports several enumeration types, but not all of them have TexInfo equivalents.

                                              4. I think it's important to directly support at least the following in the converter:

                                                • @enumerate (default <ol> is ok)

                                                • @enumerate 1 (default <ol> is ok)

                                                • @enumerate A
                                                  class callout: <ol class= “enum-upper-alpha”>
                                                  hard-coded: <ol style=“list-style-type:upper-alpha;”>

                                                • @enumerate a
                                                  class callout: <ol class= “enum-lower-alpha”>
                                                  hard-coded: <ol style=“list-style-type:lower-alpha;”>

                                              5. Additional enumeration types that would be desirable:

                                                • lower-case Roman numerals,
                                                  class callout: <ol class= “enum-lower-roman”>
                                                  hard-coded: <ol style=“list-style-type:lower-roman;”>

                                                • upper-case Roman numerals,
                                                  class callout: <ol class= “enum-upper-roman”>
                                                  hard-coded: <ol style=“list-style-type:upper-roman;”>

                                                • lower-case Greek letters
                                                  class callout: <ol class= “enum-lower-greek”>
                                                  hard-coded: <ol style=“list-style-type:lower-greek;”>

                                              1. My idea for supporting additional enumeration types in info and HTML output would look like this:
                                                @enumerate @xxx{n} where 'xxx' is the name of the enumeration type,
                                                and the
                                                optional 'n' would specify the starting value.
                                                HTML expects a decimal start for all types i.e. <ol style=”list-style-type:lower-roman” start=“4” yields: iv.
                                                Here are the types I would recommend:

                                                • @enumerate @loweralpha{n}

                                                • @enumerate @upperalpha{n}

                                                • @enumerate @lowerroman{n}

                                                • @enumerate @upperroman{n}

                                                • @enumerate @lowergreek{n}

                                                • @enumerate @enum_decimal{n} (for completeness)

                                                • @enumerate @enum_none (this could be handled by @itemize instead)

                                                • HTML supports additional types: decimal-leading-zero, lower-latin, upper-latin, armenian, georgian. These may be too much, but I have no data on how often these are used in the real world.

                                              2. The currently-available TexInfo @enumerate syntax would remain unchanged, but the '@enumerate a' and '@enumerate A' would generate HTML as above. HTML (without styling) would therefore be unchanged because the class names would be undefined.

                                              3. Enumeration that begins at an arbitrary point in the sequence would be difficult to encode in the HTML unless you hard-code the style OR pass in a variable (which I'm not sure is possible). For instance '@enumerate 7' is allowed in the info output, but how would you pass the start value through the HTML converter?

                                              4. Note that if you decide to hard-code the enumeration type, you should use:
                                                <ol style=“list-style-type:xxx;”> OR
                                                <ol style=“list-style-type:xxx;” start=“n”> (for starting mid-sequence)

                                                • Even though HTML5 (according to w3.org) brings back the <ol type=”xxx”> syntax, it's better to consistently use the style's actual name.

                                              5. Parsing logic (most likely first)

                                                • if ( argument == (DECIMAL NUMBER) || argument == (NONE) )
                                                  info: 1, 2, 3, 4, 5, ... (or start at specified point)
                                                  HTML: <ol> ... </ol>

                                                • else if ( argument >= 'a' && argument <= 'z' || argument == @loweralpha )
                                                  info: 'a'-'z' as currently implemented, @loweralpha as if it were 'a',
                                                  or @loweralpha{n} where 'n' is the start point
                                                  HTML: <ol class="enum-lower-alpha"> ... </ol>

                                                • else if ( argument >= 'A' && argument <= 'Z' || @upperalpha )
                                                  info: 'A'-'Z' as currently implemented, @upperalpha as if it were 'A'
                                                  or @upperalpha{n} where 'n' is the start point
                                                  HTML: <ol class="enum-upper-alpha"> ... </ol>

                                                • if ( argument == @lowerroman )
                                                  info: i, ii, iii, iv, v, ...
                                                  or @lowerroman{n} where 'n' is the start point
                                                  HTML: <ol class="enum-lower-roman"> ... </ol>

                                                • else if ( argument == @upperroman )
                                                  info: I, II, III, IV, V, ...
                                                  or @upperroman{n} where 'n' is the start point
                                                  HTML: <ol class="enum-upper-roman"> ... </ol>

                                                • else if ( argument == @lowergreek )
                                                  info: α, β, γ, δ, ε, ...
                                                  or @lowergreek{n} where 'n' is the start point
                                                  HTML: <ol class="enum-lower-greek"> ... </ol>

                                                • else // (default to decimal)
                                                  info: 1, 2, 3, 4, 5, ...
                                                  HTML: <ol> ... </ol>


                                              All of the above is of course just suggestion, but some of it seems necessary and/or highly desirable for the future of @itemize and @enumerate lists.


                                              PS: I will post an updated version of the CSS definition file to my website this weekend.


                                              Cheers,

                                              Mahlon





                                              --

                                              Software Sam - software and tools for GNU/Linux

                                              Mahlon Smith,
                                              The Software Samurai
                                              On the Web: http://www.SoftwareSam.us/

                                              --------------070305040705060207080307-- From MAILER-DAEMON Thu Nov 27 19:14:05 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xu9CH-0001c9-69 for mharc-bug-texinfo@gnu.org; Thu, 27 Nov 2014 19:14:05 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu9C9-0001bd-OO for bug-texinfo@gnu.org; Thu, 27 Nov 2014 19:14:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xu9C3-0008SM-JG for bug-texinfo@gnu.org; Thu, 27 Nov 2014 19:13:57 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:60574 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu9C3-0008Rn-C5 for bug-texinfo@gnu.org; Thu, 27 Nov 2014 19:13:51 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sAS0Di2S015265; Thu, 27 Nov 2014 17:13:44 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sAS0Dhib015262; Fri, 28 Nov 2014 00:13:43 GMT Date: Fri, 28 Nov 2014 00:13:43 GMT Message-Id: <201411280013.sAS0Dhib015262@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: per@bothner.com Subject: Re: real subscripts and superscripts? In-Reply-To: <546A8917.10500@bothner.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 00:14:04 -0000 Per and all, In TeX inside @math: ^{TEXT} In TeX otherwise: use a macro ... I'm thinking that TeX, either inside or outside @math, should treat TEXT as text, not math. That is, if you simply want to produce the math expression a-to-the-power-of-b, you'd write @math{a^b}, rather than @math{a@sup{b}}. The difference is whether b is typeset in math italic or roman. After all, sometimes people want to typeset a word in math, as in @math{a@sup{first}}. This seems more consistent with the treatment in the other output formats. Also, since there's already a way to get math super/subscripts, but no way to get text super/subscripts, we might as well provide something new. Unless there's an argument otherwise? (FYI, Patrice has already implemented @sub and @sup per your suggestion + discussion in texi2any.) Thanks, Karl From MAILER-DAEMON Fri Nov 28 01:55:18 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuFSX-0000Ls-TY for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 01:55:17 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuFSP-0000H6-Tc for bug-texinfo@gnu.org; Fri, 28 Nov 2014 01:55:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuFSJ-0001B4-Mm for bug-texinfo@gnu.org; Fri, 28 Nov 2014 01:55:09 -0500 Received: from aibo.runbox.com ([91.220.196.211]:60697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuFSJ-00019r-GB for bug-texinfo@gnu.org; Fri, 28 Nov 2014 01:55:03 -0500 Received: from [10.9.9.206] (helo=mailfront02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1XuFSH-0007rq-6o; Fri, 28 Nov 2014 07:55:01 +0100 Received: from 70-36-239-128.dsl.dynamic.fusionbroadband.com ([70.36.239.128] helo=toshie.bothner.com) by mailfront02.runbox.com with esmtpsa (uid:757155 ) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) id 1XuFS8-0002jp-0C; Fri, 28 Nov 2014 07:54:52 +0100 Message-ID: <54781C37.1000503@bothner.com> Date: Thu, 27 Nov 2014 22:54:47 -0800 From: Per Bothner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Karl Berry Subject: Re: real subscripts and superscripts? References: <201411280013.sAS0Dhib015262@freefriends.org> In-Reply-To: <201411280013.sAS0Dhib015262@freefriends.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.220.196.211 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 06:55:16 -0000 On 11/27/2014 04:13 PM, Karl Berry wrote: > Per and all, > > In TeX inside @math: ^{TEXT} > In TeX otherwise: use a macro ... > > I'm thinking that TeX, either inside or outside @math, should treat TEXT > as text, not math. That is, if you simply want to produce the math > expression a-to-the-power-of-b, you'd write @math{a^b}, rather than > @math{a@sup{b}}. The difference is whether b is typeset in math italic > or roman. After all, sometimes people want to typeset a word in math, > as in @math{a@sup{first}}. > > This seems more consistent with the treatment in the other output > formats. Also, since there's already a way to get math > super/subscripts, but no way to get text super/subscripts, we might as > well provide something new. Supposed I want to write a formula like e=mc^2 in TexInfo. In TeX I'd like it to be typeset $e = mc^2$. In HTML I'd like it to be typeset e = mc2 or similar - i.e. I want to use 2. Likewise for DocBook and XML. How would you express this in texinfo? With your proposal I'd have to write something like: @iftex @math{e=mc^2} @end iftex @ifnottex @math{e=mc@sup{2}} @end ifnottex This is painful, though I guess you could write a macro: @iftex @macro mathsup{THING} ^\THING\ @end macro @end iftex @ifnottec @macro mathsup{THING} @sup{\THING\| @end macro @end ifnottex It seems kind of klunky. I suspect most of the time if you have @sup{TEXT} TEXT is a single number, symbol, or lesser, so you'd probably want it to be in math italic. For the rare cases where you *don't* want math italic, an idea is to use @asis. I.e. @sup{@asis{TEXT}} means typeset TEXT raised and smaller but in a roman font. OTOH for most people it won't really matter is TEXT is math italic or roman. What they want is to be able to write @sup{TEXT} and have it come out as a superscript and not looking to weird. It just seems to be that @sup{TEXT} inside @math using math italic is more likely to be what you want - most of the time. It seems a more robust default. People who don't want math italic formatting would probably not use @math. Or use @asis to override mathe styling. -- --Per Bothner per@bothner.com http://per.bothner.com/ From MAILER-DAEMON Fri Nov 28 08:07:55 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuLH8-00014e-UD for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 08:07:54 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuLH5-0000ys-9R for bug-texinfo@gnu.org; Fri, 28 Nov 2014 08:07:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuLH4-0006Xp-3F for bug-texinfo@gnu.org; Fri, 28 Nov 2014 08:07:51 -0500 Received: from mail-ig0-x22e.google.com ([2607:f8b0:4001:c05::22e]:45974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuLH3-0006XZ-Qq for bug-texinfo@gnu.org; Fri, 28 Nov 2014 08:07:50 -0500 Received: by mail-ig0-f174.google.com with SMTP id hn15so9886212igb.7 for ; Fri, 28 Nov 2014 05:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rJHpVVVoHqvuJ9/bqj65XDqhQTQrRSQWX0fAptttERM=; b=ggMovLhEvq5qBSx1Ed4jYTMO7tab+5NqeH8ZCsBSUAnsSW5rsA1u6oJSEc5UrBq9Gp 8ykSTobeSG9s7zlNZymg+YjlpyoAgDjQFCmGBGPu+Qo2K0F2Lat1oymD8VzNZVVv0YLd rdkNcpphZx26QhUxrsESjVQFSFOdEC7Qbhq3SCbVhRi2PfzO/ruYX4UUpLj4NnTekTV/ RPaVCi+jlYDPv4IEtnnkmEdjoxROr1/hQ1HJbwL2MMzcSzQQCE5RAzo7HJvdaVRqP2WX rOe08Jp6/l3POlQozl0vgo26jvegxlVQdkHyXg7MM+Ljo4uETlQf5l5U8cnwbeeh70Ul 5pHA== MIME-Version: 1.0 X-Received: by 10.50.221.33 with SMTP id qb1mr33158085igc.7.1417180069147; Fri, 28 Nov 2014 05:07:49 -0800 (PST) Received: by 10.107.170.231 with HTTP; Fri, 28 Nov 2014 05:07:49 -0800 (PST) In-Reply-To: <54781C37.1000503@bothner.com> References: <201411280013.sAS0Dhib015262@freefriends.org> <54781C37.1000503@bothner.com> Date: Fri, 28 Nov 2014 13:07:49 +0000 Message-ID: Subject: Re: real subscripts and superscripts? From: Gavin Smith To: Per Bothner Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::22e Cc: Texinfo , Karl Berry X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:07:52 -0000 On Fri, Nov 28, 2014 at 6:54 AM, Per Bothner wrote: > Supposed I want to write a formula like e=mc^2 in TexInfo. > In TeX I'd like it to be typeset $e = mc^2$. > In HTML I'd like it to be typeset e = > mc2 > or similar - i.e. I want to use 2. Likewise for DocBook and XML. > > How would you express this in texinfo? > > With your proposal I'd have to write something like: > @iftex > @math{e=mc^2} > @end iftex > @ifnottex > @math{e=mc@sup{2}} > @end ifnottex > There are many types of mathematical notation that may not be as easy to express in HTML. Rather than implement this and require document writers to write "c@sup{2}" instead of "c^2" if they want it to come out right in HTML, and then adding more commands later for other mathematical notation (e.g. fractions, integrals, summation symbols, square roots), maybe it would be better to look for ways to create an image file containing the typeset notation and include it in the HTML document. This would seem better to me than creating a lot of new Texinfo commands to replicate the functionality of the notation that already exists in TeX. The other argument would be that this use case (displaying mathematical expressions containing superscripts) is so common that it is worth adding as a special case, even if the general case is not implemented. However, I think it's likely that any document containing mathematical superscripts would like to avail itself of other mathematical notation too. (Taking the $e = mc^2$ example, we might want to give the expression for the energy of a moving object, $e = \sqrt{ (m_0 c^2)^2 + (pc)^2 }$.) > > It seems kind of klunky. I suspect most of the time if you have @sup{TEXT} > TEXT is a single number, symbol, or lesser, so you'd probably want it to > be in math italic. > I don't think numbers should be in italic in superscript. makeinfo would have to check whether it is a letter or number to decide whether to put in italics in the HTML output. If it is a more complicated expression like "n + 1", it would be stuck. Therefore it would be better for the author to explicitly encode when they want italics in the superscript: e.g., "@i{x}@sup{@i{n} + 1}". Another idea is to have a command explicitly intended for mathematical superscripts (e.g. @power instead of @sub), and not any general typographical use (whatever that might be). However, I can't see that this would achieve much. From MAILER-DAEMON Fri Nov 28 12:41:29 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuPXs-0001hP-Sl for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 12:41:28 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuPXj-0001fc-TA for bug-texinfo@gnu.org; Fri, 28 Nov 2014 12:41:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuPXc-00041p-Qb for bug-texinfo@gnu.org; Fri, 28 Nov 2014 12:41:19 -0500 Received: from p3nlsmtpcp01-04.prod.phx3.secureserver.net ([184.168.200.145]:50084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuPXc-00040m-J8 for bug-texinfo@gnu.org; Fri, 28 Nov 2014 12:41:12 -0500 Received: from p3plcpnl0585.prod.phx3.secureserver.net ([50.62.176.112]) by p3nlsmtpcp01-04.prod.phx3.secureserver.net with : CPANEL : id M5f81p00N2RsmEA015f8yH; Fri, 28 Nov 2014 10:39:11 -0700 Received: from [124.207.38.54] (port=47137 helo=[192.168.0.103]) by p3plcpnl0585.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XuPXW-0003oA-6j for bug-texinfo@gnu.org; Fri, 28 Nov 2014 10:41:07 -0700 Message-ID: <5478B397.1010003@softwaresam.us> Date: Sat, 29 Nov 2014 01:40:39 +0800 From: Mahlon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Texinfo Subject: @flushright command in HTML output Content-Type: multipart/alternative; boundary="------------050901090904010404090002" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0585.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - softwaresam.us X-Get-Message-Sender-Via: p3plcpnl0585.prod.phx3.secureserver.net: authenticated_id: sam_texinfo@softwaresam.us X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 184.168.200.145 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 17:41:27 -0000 This is a multi-part message in MIME format. --------------050901090904010404090002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 28 Nov 2014 RE: @flushright command VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64) BUG: The @flushright command is incompletely implemented for the HTML output. 'flushright' implies pre-formatted text because the whole paragraph is being shoved to the right margin; however, for text in blocks that would normally have wrapped, this is inconsistent. Outside an environment and within an @example, @display and @format blocks, flushright looks great in the info output. /Carefully constructed/ text in @quotation and @indentedblock environments also looks fine in the info output. However, the HTML for all of these has issues because it is directly styled (

                                              ...

                                              ) rather than calling out a class name. * Outside an environment, the HTML is not pre-formatted, so the following return address example is all on the same line. Explicit end-of-lines ( @* ) will correct the HTML, but cause double-spacing in the info output. * For HTML output, @flushright within @quotation and @indentedblock environments suffer from the same problem as above. * For HTML output, the styling for the @example, @display and @format blocks overrides the @flushright, so it appears to be ignored. Outside an environment (with and without explicit line breaks):@* @w{Generated HTML:

                                              ...

                                              } @flushright Jungle, George of the@* Ape Mountain, South@* Bukubu Territory@* Deepest Africa@* @sp 1 Jungle, George of the Ape Mountain, South Bukubu Territory Deepest Africa @end flushright @html
                                              Direct HTML Output for pre-formatted, right-aligned text: Jungle, George of the Ape Mountain, South Bukubu Territory Deepest Africa
                                              @end html In an @@example environment:@* @example @flushright Jungle, George of the Ape Mountain, South Bukubu Territory Deepest Africa @end flushright @end example My recommendation would be that instead of direct styling:

                                              ...

                                              The @flushright should call out a class name so we can address it with CSS:
                                              ...
                                              or something similar which would allow for definition of preformatted and right-aligned HTML output in any environment. Cheers, Mahlon -- Software Sam - software and tools for GNU/Linux Mahlon Smith, /The Software Samurai/ On the Web: /http://www.SoftwareSam.us/ / --------------050901090904010404090002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

                                              28 Nov 2014

                                              RE: @flushright command

                                              VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

                                              BUG:

                                              The @flushright command is incompletely implemented for the HTML output.

                                              'flushright' implies pre-formatted text because the whole paragraph is being shoved to the right margin; however, for text in blocks that would normally have wrapped, this is inconsistent.

                                              Outside an environment and within an @example, @display and @format blocks, flushright looks great in the info output. Carefully constructed text in @quotation and @indentedblock environments also looks fine in the info output. However, the HTML for all of these has issues because it is directly styled (<p align=”right”> ... </p>) rather than calling out a class name.

                                              • Outside an environment, the HTML is not pre-formatted, so the following return address example is all on the same line. Explicit end-of-lines ( @* ) will correct the HTML, but cause double-spacing in the info output.

                                              • For HTML output, @flushright within @quotation and @indentedblock environments suffer from the same problem as above.

                                              • For HTML output, the styling for the @example, @display and @format blocks overrides the @flushright, so it appears to be ignored.


                                              Outside an environment (with and without explicit line breaks):@*

                                              @w{Generated HTML: <p align="right"> ... </p>}

                                              @flushright

                                              Jungle, George of the@*

                                              Ape Mountain, South@*

                                              Bukubu Territory@*

                                              Deepest Africa@*

                                              @sp 1

                                              Jungle, George of the

                                              Ape Mountain, South

                                              Bukubu Territory

                                              Deepest Africa

                                              @end flushright


                                              @html

                                              <div style="white-space:pre; text-align:right; color:red;">

                                              <span style="text-decoration:underline">Direct HTML Output for pre-formatted, right-aligned text:</span>

                                              Jungle, George of the

                                              Ape Mountain, South

                                              Bukubu Territory

                                              Deepest Africa

                                              </div>

                                              @end html


                                              In an @@example environment:@*

                                              @example

                                              @flushright

                                              Jungle, George of the

                                              Ape Mountain, South

                                              Bukubu Territory

                                              Deepest Africa

                                              @end flushright

                                              @end example


                                              My recommendation would be that instead of direct styling:
                                              <p align=”right”> ... </p>

                                              The @flushright should call out a class name so we can address it with CSS:
                                              <div class=”right-align”> ... </div>
                                              or something similar which would allow for definition of preformatted and right-aligned HTML output in any environment.


                                              Cheers,

                                              Mahlon





                                              --

                                              Software Sam - software and tools for GNU/Linux

                                              Mahlon Smith,
                                              The Software Samurai
                                              On the Web: http://www.SoftwareSam.us/

                                              --------------050901090904010404090002-- From MAILER-DAEMON Fri Nov 28 14:01:27 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuQnH-0004e8-0B for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:01:27 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuQnA-0004dI-Dy for bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:01:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuQn4-0001Yt-4m for bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:01:20 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:42388 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuQn3-0001Yh-UF for bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:01:14 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sASJ19ve026144; Fri, 28 Nov 2014 12:01:09 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sASJ195U026142; Fri, 28 Nov 2014 19:01:09 GMT Date: Fri, 28 Nov 2014 19:01:09 GMT Message-Id: <201411281901.sASJ195U026142@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: per@bothner.com Subject: Re: real subscripts and superscripts? In-Reply-To: <546A8917.10500@bothner.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:01:26 -0000 Sure, sub/superscripts are most commonly used in math. Thus @math, as in @math{e=mc^2}. I never expected anything else to be used, certainly not clunky macros. This is why @math was created in the first place. Is your proposal really just working around makeinfo not recognizing ^ and _ in math in the first place? It seems to me that might be implementable without too much trouble -- the parsing could maybe be treated like the accent commands, so that if the next thing is a non-lbrace single token, the braces aren't necessary. Seems to me that could only help, in any case, if it's doable. Patrice, wdyt? In HTML etc., the output is always ... regardless of text or math mode, since nothing but TeX distinguishes. Having been drafting the documentation, I can say that it feels quite clean to say "use @sub/@sup for text, @math{^_...} for math". It's no problem to implement @sub/@sup being like ^ and _ in math mode and doing text in text mode, etc., but, I don't know, usage doesn't seem as clear. If I may dare to generalize a tiny bit -- in principle, I'd rather that we recognize TeX math in the first place than invent new Texinfo commands to do the same thing. karl From MAILER-DAEMON Fri Nov 28 14:35:59 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuRKh-0000Px-7M for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:35:59 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuRKZ-0000Pq-UI for bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:35:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuRKT-0007zd-Rn for bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:35:51 -0500 Received: from aibo.runbox.com ([91.220.196.211]:42829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuRKT-0007zS-AW for bug-texinfo@gnu.org; Fri, 28 Nov 2014 14:35:45 -0500 Received: from [10.9.9.207] (helo=mailfront03.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1XuRKS-0006oj-F0; Fri, 28 Nov 2014 20:35:44 +0100 Received: from 70-36-239-128.dsl.dynamic.fusionbroadband.com ([70.36.239.128] helo=toshie.bothner.com) by mailfront03.runbox.com with esmtpsa (uid:757155 ) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) id 1XuRJv-0007Ny-Vu; Fri, 28 Nov 2014 20:35:12 +0100 Message-ID: <5478CE6B.4020401@bothner.com> Date: Fri, 28 Nov 2014 11:35:07 -0800 From: Per Bothner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Karl Berry Subject: Re: real subscripts and superscripts? References: <201411281901.sASJ195U026142@freefriends.org> In-Reply-To: <201411281901.sASJ195U026142@freefriends.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.220.196.211 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:35:58 -0000 On 11/28/2014 11:01 AM, Karl Berry wrote: > Sure, sub/superscripts are most commonly used in math. Thus @math, as > in @math{e=mc^2}. I never expected anything else to be used, certainly > not clunky macros. This is why @math was created in the first place. > > Is your proposal really just working around makeinfo not recognizing ^ > and _ in math in the first place? My use case is primarily *not* math - I mainly want subscripts and superscripts. For example function prototypes: (list exp@sub{1} ... exp@sub{n}) Syntax descriptions: list = nil | (value@sup{+}) Language names: Schema as specified by R@sup{7}RS. However, I do have some need for math: A quaternion is a number that can be expressed in the form w+xi+yj+zk, where w, x, y, and z are real, and i, j, and k are imaginary units satisfying @math{i^2 = j^2 = k^2 = ijk = -1}. The magnitude of a quaternion is defined to be its Euclidean norm when viewed as a point in @math{R^4}. I want some sane way of writing i^2 and R^4 so I get tolerably-looking expressions with superscripts in both TeX andDocBook/HTML. > Having been drafting the documentation, I can say that it feels quite > clean to say "use @sub/@sup for text, @math{^_...} for math". It's no > problem to implement @sub/@sup being like ^ and _ in math mode and doing > text in text mode, etc., but, I don't know, usage doesn't seem as clear. > > If I may dare to generalize a tiny bit -- in principle, I'd rather that > we recognize TeX math in the first place than invent new Texinfo > commands to do the same thing. In the above example I don't care if I have to write @math{R^4} or @math{R@sup{4}}, as long as I don't have to use conditionals, and I get a when emitting HTML. -- --Per Bothner per@bothner.com http://per.bothner.com/ From MAILER-DAEMON Fri Nov 28 17:10:49 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuTkX-0004Wc-9v for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 17:10:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuTkP-0004WP-51 for bug-texinfo@gnu.org; Fri, 28 Nov 2014 17:10:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuTkI-0001K4-L4 for bug-texinfo@gnu.org; Fri, 28 Nov 2014 17:10:40 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:44138 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuTkI-0001HL-86 for bug-texinfo@gnu.org; Fri, 28 Nov 2014 17:10:34 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sASMAWrZ013791; Fri, 28 Nov 2014 15:10:32 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sASMAW1V013789; Fri, 28 Nov 2014 22:10:32 GMT Date: Fri, 28 Nov 2014 22:10:32 GMT Message-Id: <201411282210.sASMAW1V013789@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="w8hSrnmDTh" Content-Transfer-Encoding: 7bit From: karl@freefriends.org (Karl Berry) To: sam_texinfo@softwaresam.us, bug-texinfo@gnu.org Subject: Re: HTML Output for @table and @multitable and misc. In-Reply-To: <5471B2F1.6070609@softwaresam.us> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 22:10:47 -0000 --w8hSrnmDTh Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Note that the whitespace in the header is retained, while the whitespace in the line items is compressed, which causes vertical misalignment. What I see is not related to whitespace in the input. Consider: @multitable {California} {Sacramento} {California poppy} @headitem State @tab Capital @tab Flower @item Georgia @tab Atlanta @tab Azalea @item California @tab Sacramento @tab California poppy @end multitable The HTML output looks very clean, being the simplest possible generic translation:
  • StateCapitalFlower
    GeorgiaAtlantaAzalea
    CaliforniaSacramentoCalifornia poppy
    Browsers (at least the ones I tried, the usual) center
    cells by default, hence the cells in the heading line appear reasonably spaced. On the other hand, browsers leave zero or very little (1 pixel?) space between cells. Hence "Sacramento" is essentially running into the "California poppy". (Screenshot attached.) How unfortunate. I agree that it looks bad. HTML does not (to my knowledge) have a reasonable way of using the "prototype row" method of giving column width definitions like the above (the @multitable line). makeinfo does already make use of @columnfractions specifications (, etc.). I suppose we could insert some random amount cell padding in the prototype row case, e.g., 1em. That will look good in some cases and not so good In others, but maybe it's better than nothing. I'm not sure. Karl --w8hSrnmDTh Content-Type: image/png Content-Disposition: inline; filename="s.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAdoAAAB/CAAAAABtKVyaAAAACXBIWXMAAABlAAAAZQDd0Sc5 AAAmgUlEQVR42u1dBXyV5fc/d90bIN2xwWCjW5rRIiXdIvwICZVQUlBKJURBGumQUBEQREJy GzFiCYyGbazjxlvnf57nvffuIgMnDgX+7+HzYfeNp873OfHEeV5AjV5TAkWj15RA692vrdRq LNCg1UiDViMNWo00aDXSoNVIg1aDVqPXFFoFZVFgJEoKXbwwonKk3BSjoGgyCU9/RUHhmc// DgkmQSUTZSebBJP8Ijnwb0NLnLRlNQFgNBmlJ1tI7xmNxucGX1EUQU1MJeQql39YoCa1CkqK ELx97ZrNP5+KFV4YHwkhSZEu7Fq3ZvPBm9Izi5Hwp2UrNqH8tOcybl26dAe99s/rhKuWr1i5 itEKAfHOonULY59e7qsntTJeHlIciJzLV7+Ekoz3xs/5IPRJzom4e/zM6c8LPokgHhlUwYHK 8an3nfFZuRixPkAhlET89aPPPsl84lUBywH4oykvoHUCC2Ug/gpesJPq+bpAK2N8E8Zv38J2 TnAQJQlPgQd8ixlMFYqCyWg0Cdw4ZmE/cIBUyUjokk6lJyZBZj9zx0UB1+Sncjx8fQBaJTCz a2I5MGOg2gBZFuiaLk3Y9Y0StVHW41hwhrtoIIGSzTVhBQroD1Atb6D1dHDIV9mvYsWK5bMQ D8EbsJubJ5HVjdspmUolOSbTwJotGI101+Y56Txedbr8rwzH06E14Zc6nd0nwZfOHVlR9xSD 9hwUgJUEhQ0PJLKUBnwX3Oz1TLWyG+pfObemUMBd+cA+/zdnw0L29ekWZ1F7zByYDbDEOaUw PyY5Lv4RKkacQGIU/7gfQLo8j6W2edz5y5evXKaGW6RW5r6Uwv7aGhRrU2XJ/Ny26i+h1Bqx P+jsDMzNwTjqupm1KoMdlG5Yu3oGZn7/QedGDYJGHGDQbPUtSlJXq77fOKR+fHZCm/qtxp7L batkzGgBDs7HeIdIv04Kefek7k3qtxi4hX6Sqi7drHTI9RGNmn32iPQBjqzTqDPift+SoIPq 9f3fRby2YGjbBg3fmnaVcspjaN9Gg9ngmKFVMPPbXo0b9fgmgwr7o0Kdt8MRv68T8D5KGaMr V19MeKet6NOkUc/lJlb1XaWblo05M7BG78eE4SWBth/Yw4BQE++WxHer9UnBKAKZket79NoS 4IbJHtqjXhjnwX7buX8q504jC/hzPoCxZHElifcGobBaiFObdCbR4AZ9K7LrN6+jXrW1uJnU MSsE6iN+SeUyKrQWhRcNLQb7ObKyHH3PIIZSq7cjdgCoaMBQX4AtiKcrck44Vo+kSiwHV+hb DKBqHlQozxXyInsSDud8jSYFM0WT1TOITGqt/t27ZGI4BHbq240Y6bgZ8ZeOFei9br3bzUXS lDq7wHdq6exgCZPbvyZS++AIx7luUJgaN+Uv075PzwAC7HPmoIGrPRTqUIkA7EXQNgAogni8 YxXC9e0+HaYgfg6Nuvdrm18HVa4SEnkKbYn3evXt27enQTFDK98n7eTctLkLQOG7GNdcB7MR S1GvOoLr7R0cY/HGGwAF2nQsAFApXcAV4GoHzq0bt3z5oJUVQ3tVgOyg431mR0LAE5YjcwtM 8abE+LhbJQE6o2jAAYS5nimh02UAPs4wpk8EqB6dq1GIEaeAC9w0e13McXpoSo5/mNQCIICs 3C7q+oF30Eg1KXQIzR6yET+kNPFch6ekZj2KT9lLFVhB/twL9ZCp34LLd4grXQE+RHkyQLfM 817gaDcHJwE0ScaRAH7BpqyQIqAj0JdTHYteIe/j5XOjiM/62f4Fnbmu7Z+JttAKW5r5sGbr IBAFK7QmXEqvvtmySVAtatavuRotGHE6vRvDoeV6Hw+9XUinantye3fxIhU8SqK98EloZYyb GcC1syPMxMy8hdarZkBgYKB/lhXaqgA1RUmU6lC3Q1IoujK3l0PBntAbqefNQIX6deF2jZu0 8dZBCwatO40nXko3ivw7chxClg6t5gj2DlEElAotDUO4hbNzdSMIfC3QZjHPdTY4mvu6M2zL lftgIlPtAHvN7jXp8D2sx7i4MVvOofWCX6joGyS9Mx6HNo45zSkdKLWDmzMZvil5De2fbS2S F9AYjUZsBlAQ8UIxHZx/F/qshOYnywMNDwUXi6DroAyD1gP+wFy6HP/BHLKe2JfVl/h62Qzt MswSMbGQA5T6ePGWIjbQZsj040ticc8Bvfv06jmsZ0iuFLKIR4sDdJHQJLCxq4y1aCg9asH2 uqDTmaV2JxnZcOorcx6H9gGajLid7jeau+pLus5zaDtiuolIsUJLUtkQMzOxMUApxMS3ARbU gLXhUG2sPRSNRIGG5+VHdu/Tp0e/wR8zaD0hNA+mxl4AtCKuX5PERuH4GbjZRdJ1KPVDUsgK PiROTkDjo5JmaAepClnAHe72sIebzPS43NkYMkXdSNSXMB8Kr+9LQ3JFmqNBbEkWnkPrDu9R 1rPAznlDNrQfEaLxzAIw0TjPNKbrvyC1hGWJs4jB5Dq9RZjNJI3sAddTC3kQH7olo0SOVTMm C6g8yBA4tCEvJ7QG4nnrsYvXr/+gqAO0TKRKXiIGttiw6Qg+8nCCigvWVCfNQ9AacRxBO2HL 1khMaw1OnsOXr/ri/Wpv383dpKuEF8qCk0OfJRuXTaraIQ5ppPPGpxvbgEUhO+tgzPaZ+Ryg /n3JCu1M0g6jt2y9iOupSh3XzvX5VxTyIepuDVatfpOs0a9kbXaSYoFiJlNvsHeCBchsiYOu 3herlk7uXH7NSy21BuxOiIGnGzWo4GFm2OKbk3y5e3QTySN01DlBnfx2xEkaTu7JR43yLEje 4zlfgtvNw84eWtzPFbRsCvlMDeaGeznaQesE4gjYOYB/GXBw5NC6QIAXG4R5bSHoGgEUY3PI h4pQTTzzz8ObjQlUR8c3de4wjZ5TvwjMG2jdHaGrFdqDkJ9NNOJUNhh0pv8+YV3yUiANuvuI 5Du6O3OnUZpIrHLwIrfOfi050pAPzr2c0EoYOqV9GfKUHCv8L1TmA8/zzVm7Ghow5UMfcGwV X5krZBqNLi3DnIfPiRc3plenDu9SZ/SJXDr9zL7eWxZEdsreb+AxGcWvioGuanQfi0L2hN0b SwDU/hFly/IA9bJ1vkysJyJebGcPXtMj/g2FLKC8sx0NDLzb/CCxnm7oQWZhGeJZ6n7+4WwY L+zpWpgYVKLz0kTxZZZaJlAp92JjYm7cN/JZUWpw2o3o6Oh79MN0K/pGBsZGRsZy31Z6GBMd HZPM3hETYmOu3YrP9aS4Ot+ccvsalaPnA9t70deS8X54dBSbrSOmHsD7MdcSed+6HRF5jRco x1+jAhOpW6Rdj74jiRExVx/RxY3IiNg8GG5QDtFR4ffMakfBzKsxV9P5pFzqrWvXbqUq6jgt Ljw6gka9xqjoiLuiOumSced6zI17aXzEfTUm3PBfrik/a/BjmfdWzMha58EVdQ3AOgue/aLy xL2/5qPyeCIlOzWbjfKG/Sgqj+VnvbD8UP6lLRCKbJ3+t61/dsVkWwa9vIt6Cmc6JzMDUb1W zD/YCghfC2GI8geoZL/zNxpnSaSWo6jJ2f8WqRXMhdoUqFgKVF9XLyzP84DMGVo6rPnKygAV PX4bLVXJqR0vp9S+BEQOjHdNnz/+S4P1CpO2o1GD9r8g5RXdS6hBq5EGrUYatBpp0GrQavS6 QMunAFT6216pYp6L/OsXn9jIqk5i/Tsut/LMbbR/Z5ftqwStkj1BprywmbLHZiyl3OxEZ3uM 86wuivKSzAL+q9BykUXDw9gbd5L/dpQH8f/Ww9xILZVyLzbhz1J75+a/M3hVULwdm/IsqTVE J6KivHZSq6B+ezMXALui/Q9n/T1WK5gJgWwT9l9LTYorNEYT1wvBYZyNIhbWpT21PBmvns6j 4ApFxgsAI1npOb/Agl/e57u/XjeFnNQD/IcvWDqrcxGXdeYQFzWcBs2xPGo0i9HEHkj8JovG EQ0yoiFgAFtJFVkEDgsXeSq0a+x0JU4QnAqaoIRRbzRKEhZ3ZGtmNgEzlCXLW+SRPlXhhmQ0 Ugpz7s8tVlThaQC1Y3hog9FMbLsdj1NiP/A0jGXQ8parMajS3wtiejkVsqEPjHnEV6yipm9n IS5qtA2PZDHH8siyNf4mOxrHZonEvAAiPo0RdLu29yT4mAuOAhX5rkcmtenWhTpRNfSyJdLH hHXAYF5XUesgPi+bFUwtEDAcNjwul5Z1LVG2Si237gqLc1I7qZI7t+AlhZbq/Qv0UASjIJhM KGbwfWhhy6fPPZBGLZbRuG/+9KWX+ebLWfPx4qJxZwmWpO2fzdyHR4feRDSNX0rvZZz6bvrM dZH4lC0WlPiKXfNEaJTMOsnn4DX542mjziOHFo0X1s6csTyUyhLxt2F3xI3T5h0mUcbtnjB6 ytQxu1BKPfbttFkbr+Nz7tqmRPvhw6sw2ERlGCZO/uSTyZOmT0lF+fqOudMWHdIzqeXQUrc6 tWTaV8cNbA/b/Z+/nPrFT0n4yk1l20ArdnLdgUbSQKJg1LOFUGFuPvBycOh3nXgd2wN0HpD/ awM10cVnWb6isACliHZg5+M0cSj8jmRrq6IBPwZ3H2fw2/S07eUSjoRV8lDYgoKE5cDO26sg bOLQSrgR3HzcoNhctlNmIizp4OkFTp+hHruBnad3ATKROBQ8vJ0g8KfnDHUl6Wzjdii9ldNZ yiDV2cfL28PbBW7jtXyO3p46z4FpdFuV2vQxrjpvnceHCSjrq4CXl71zu+uv3NKiDbR6n/L3 sweYioCfQc+T18MnwbuCJLaD98NuHKgH31Pz34CSS6IvPEBTU5h4+fruNz3hNwZtLdKdq76+ GBW5xbPMpRwjfqi7GMs4JuJBGM403C0odvNabEy6wqBVcP/McxERB32d9hOcE6DA/87e2le4 4CE0mSrCmduxMQmIi1eERUWsdgi8hs8zHCKVcQcqy7gIvqb+KV+PjY1MXqxrlo43xh+/HHGu G8ym2wxatvt2dOi1S31ZUE/6pH2XIi9/CO/qX2GpzYQAsjES/jZnzrxpWxAvlapPehMze9sf wE0uLUlL43GPBvcQPWAG/RZxk+NbTHkeLAyHVKkV1X0P+CO9YMypNBG3OHZBvOVXNow5UlCa O9U2tpYUNnTCDBwPbZPo/SUwBdOxOiRZbS3zw+Db59vapuAcmIB4Kn+Dh3zbk4RXqxQNVz0H WTYE5MtEDi0ecO8h0dMHbxaI5BWkN3pC+KsmtvD48EUiYX2fBfm0QvwW1jO3FXfCV9SNt7E4 EUMvOIXo4n4DRcmIA2EPu6nvZVHI5IjcWz957ISh0A+NSg5iY8IOJOEKWdnlZKklKCkLkqSo 0MqYvHPGB+M+gsoE7STYSK4pMXoUXVSDO+TRkKDhzdWfjJnUHz7KKfdczIJhWZcIyqUf/EEN pezjWsBh5q8JR+eOHzW9JCSYoR0FJ3hlZ1DDJDy3cMKo6fXplqS8qtBmOfilMoWsT8kKgdYs MM3T3Y3+ecEkbAdhHOaJTECdvQ3kTRmxFfVkdnMsHFGhNeJyTztnJydX6Jrj4FDC8BIFMui1 36ET2/4IJTm7OLQyHiquo7Qu4IeZBO0+NTZwGF1Uh3uq2z3f1d7JydmN1PnzDD1lPGxXlwU7 LIOxApNEaSSsYxW41xCoYGd7uGGGth14uLm7u3l4wHbM6q5zpIcurEKvLLSmevmPocB1Xgy0 QYKx05gRI0eOHDt4F74FF7OhdfJhPmQO0OLvhQqsiTPhVeiZI/NNOB0c/Cr6+Ze2d/qdOGUD bSpeq+L0+R0DGsEXswjaX/4MrYC7vYpvSzDhcRjzXNCK2Adc/f38/IvBG7eYh/41fMrgkrpD nyvpBmxohbYt9H2fGj5y3OBg6uBNTqfocRz8+gpDi0thHBpFIoyEtuS0kM+kjuVMOJz8WFFQ snrAaQu0JhzMQsXpplUhk4eygm3u3w89cmA+jRbFJlC5in9l/8DyxFWytaXQJIoygzYFjxJT KW3Uk9DWIGglUU/u9w9sULsZRj8HtNRjk4pBYOXKlStVLU4euoJ7oa9RFkTWmQz0V6huhXYY j+VWu0NFcqFFAQe8wtBSWxN9829V95lGM4UcVrraXXVeOQN3uTXSs1OAXJo8sEAr4jbnNsyb 2lfA4kbhfFjKjHZbeCcn5gu4x6NeCo8FCS1V/ibKDqUl2Sy1KXiYhjckSkNJIf8J2vpwC5mW +JAQkTGhMb34HFIr4gLdO+qRN7s9GmXh1QLtkvlg1QAVU1lkmCtcN0O7371DJnfcsvRYRhdD KX4r8QorZNZNQ8o6D9sXejl4Z0/oRiydB813Xbx8auWI0yh1gUEnr+yoQcwV0bMQg5aEsDW8 f+bK+noeDNosqE088SyzI/LowII5KmRi30RYqZhMJqNBGUQOjNLQeWF4xOUUxJIuqRhZxueb 8DMfFYMAgnYK7GfQhhKKevwfjAuLvHIbNzv774041KPAc03zkn/YDg7JvPSsunBbeTPf1pth 4eGXJbktjAq7sLiKM4P2NNNcVOI7+y+GHV88KgZHQKfgyxsaerEKvarQMmwjBhUAO2dnKMeO kJGlZeXAwYm85UhU7g7RgRMUW80mcpx9jOoe/2vdQOfqNG0oeZxcagVxviu4uLT4AbrnwHwR Q3zhCh92mPAbaJWCRyqBsw9sQG5rcWshcHH33Q8VuNT+rErtUHo3qiU4eJH8pk1xBFenrt+T 2/z3oRVxt7d3Oh+bmnAkDE0BJy97Zyc38r4v1gJHD7fN9eEacp+cbMyMIuDoZGffNw7vvgV2 7g5fDHulpZbNsxkvbft64YoDN83ztzd2LVmw7ngy+ykeX7FwUwyfaPzmO3V/vIyJPy768ojY l/lYwvxNbOh08ruF21OTZ+TUxWW8vuSHTHPOD9auykQ5ctvihdOvIK78mp1zc2n1ovV35K++ JwV4cmoseytuGvO28PaP3yz49ACKxqPLFu3WP5h67Dm4TIOYRQckcxhJzNLthiUL53315ZcL Pk9DvLv56+/O4Y451L/uTz3K23h12+JFG88ytZy0a8mSo/jH1Fuv2iTyYys/iiiaI0AkkV9m T/zbLA/YTLZLrDv8AB2TuCxaVw/Ep03cmDdiWGb6JdvMFHWF6YmFQcvBWtYVA/H5p4WyS7e9 KakhadamsRUIxbZw24evJLQq39i5s4LlzDZ2qJ4gquE07MBatZ0mvtpKcrCuwf9mT3/b0/sg MUDhx9WyhTkyxMacFmf4hnHrGarqIho7tE9iR9Qq5rSSmo9klNVz/HhG7DWTqC77CbJsfJ6l H8rFvEpn/mkyk1oNQVTU83HVzLNbzlYz6W1zhV5VaP/2FMDxum4Arp2DX5d9Ca8X/QNo2aJ8 ckJCqvD/ZrfR/xtobe2nhuzrJbX43DtbNXolpFYjDVqNNGg10qDVSINWg5Yv54ii9KfD5c0T b4rIt+WyV/563k1Nk9OMlETJpdzGfj2v7/7UJ9nFP9ZsUTafJMv3XYui/NdF8DTKKwJtroYx yj9i+X/Li9xFEr6GUsv2hV0bX6948WqDDz7GBbYIHox4n6/CKtKcgPxlf/6rrcBGHA7nn+Al lfBzp3KFKwR9dOE/QJlKzFzSumzRSm+vfCykScITMAv1WNsrma0V/NKouPeMv4JYxMMwNxdB Ti8JtCjNd3D079KroTt0YNERpLz4qVYGHAInEO9CG3aM6idQsvuQYKRHkvkUMFliWlpWvw0j q+rOgH0hWD2xS7IejUV8GwaeQX3al4PRts/4nL16wWbmZfZbPV/L8tx8k1+wP+Z5fmvm/Lla MjtLfR0K3Gbwl2Vr2AoeKQZF2vZuU1hXIMkmexF/h/EEbVlIRAEP+rh37LVZ1d3mw72sNbLW AtkuoansGDpZfsy8WLkh21TRNhebC7NhUDjr+BlieTr5Y7tei/Oh7jm2dJY8sh479tgcSsyh PUm/kjPZSeV1IdUmukfOjsaxCZ7lm0+SLHFX1iP/BFzn2JAHOR7eK1tW2NTz22SbJTVLbjbf 2XusQHU7sjnK+fFTBtm6FH4D29TPAVp7AP8j43FH9+/Zaqyw5Y0HNmcUMmgnUOXSU1jqpez8 dcXmzD7lzwcHquULSQZrRJBsY3YfO4tQfoItf6pvttOS55N6YKOtwqD2XeRRdia27pwSERwc lcLCY1SpNZ2KQYw+XRGOnL5ISiwt/OyFu1yL3zuahjGnwxAfHUnAW2fP3+bL9LEn2UK2/sa5 M5fjzMe0s63Lp1A0d1YU7108c+G2UW269ODSmfN3BML/RCTGnz+ZTvJ3+8KZi3cFXqET0ZgY GhpNZiArLDg8w5zm3oWz4emMV1nHYjEuOPQa7ybvw+RLJ08GM75lRJw9f8fSKaTKcFCdHMVb VBCv2kNZUVRoTXg5RMDkc6NgduRRE9XjemjINX7wqJ4yvx96yoDiyQhMCg2N4gsiqcfZPkvx ftiZ87d4Gzgbqd3H9Rh19mKCuU/eOX82gldROXsJUy8ERxrYReaxm/ggJPQG21yddOw+7yNS 1IW0FyK1hMYIWEzcV9QPGOKPfh46gHanUbZRyDgUHEEHAWg63ZKeFl2YSSmmwYap+diZ7d/D gtXFAEquY2n6whnEO03z2+vAf4O66G7AHvAz/zwZ00vKkMIOOijwaRJv64KyYGfn+ZWICdD0 Nz83OIqZPQpS2mJfst3n96Dt8QBH8JqK4a08wGnQQ55mbhGwh9Yh9PwSDPzV1x58ZokiblE/ A+TNjv1tawdQaF66epbnJseOTGaJqP/i3WasapXWi2ap1WM5iMOj7KNFdvAQ741yB3AdcpNy uQJ995R0hhh8BI1PVXcEt7EZXCFPYVtxijgC+EyOtxz+zIJK9n3oCVBpL9Mq6fMLUXZtQ5i1 gwrBdR11ul4sy/Pw7t7SOnCdksa+/dUrncn9XaeqN/MyQsEGWkOpktFcg/AejoubLNq8fjSU uEWNNkP7FmLozvKwddchPF44/4QdyxrAGHo6FSrUnrd1NeJaqFx36q65HvmPYRYJaAjihZqf rts8uzT8xBW+CedArZ1R6eS5EHP1LYav2PptM3ZuNAoDoMHCHesGT87EOMhfecCuhbcwoeG4 VVsW14WvKOldKFJ70LZV/jCzaqf1m9qpafpB11Xbp+UvFIF4EUrXHrFjaTlYj5jRD97/defO vYghxb0/2L6iMQxDvrl2KKna7K+phtWcsXbznLKwm9ipQluRbG3cTwNhwpGtQnpTXff1m/ra 14tH6jdFA0bsXphIva5g7f7b1tSCL5AhMgMFoe2Q5VuXtYKxFsXKoK1S7Yuds0p57KEih0Hj 5ds/8C5B2IpOHpXbbtjY36F+IvsAVGn/wdtXtYR3iddDgcUb4waYlqefBHosMKSyUbZ+0g4z +GG+m+EjTLdxo0xYm335Jr0XfE/Ni/f3PKqQY1Uqipgl4Gooepa670IYhGmqG2VMZ75TZNFq fNeLjI+6A/h1/XjTA/otpTK9nf6W0xXErdCGC2+GSNDqPmXGDsVUplIfNfS5Q9IPjguJbbu9 KWsBw3yLX0OSziGiTIXaDRDxArivJ/2x26EmvfUNbOXn7GYNgu+okknVXX6lP0YMAqtfTv+r VYsqHigoZmiZG2XCxfADFfEN9GO7okfAPGaonJfzGj0Cu9mU/x8Fi9CYlrtRUipTqVnddZZD rQ3YD4pdp3sHoXUc7netnkwPlsOgLBTsoBeSUhkOi6jTgd1XBGd6XeeDiNspJzI0/iWu5Gns yRMxP1b1rJiu7N2xazO0IJhsPeTqkCzhJV1QAhpM+B2MQFLIc1A0CQIp5EkoGvEGBJmhJfV3 ++DOTYfLQpZZXB6s6VGcFF3T02y7UeLx3ZuO9IXDiI3c96NeYDtzSDQC7ikGE2NZ/JHdm462 hUtICrlemmQwZhSDm2g0Cb3YRrsGxVK511TbQU+C9ZaBfZTSJR8xdzGsRAPVNNqp0X1WyXUw kMAyYiOIsvF2WNV2bfq9POup2dAKOJs6hh5reJ9Agx5Di/oa8DK0TJbZdy8ToWqSbMjCSpCh qNDKmPzHns2/v0dqSR0IGUhbfUlMUDL6wD7sT766yYD3GztFogD5Q9BgwJBClU14Dpo9YFXb CANQTmruwfdSvvP0kxj+IbRZUCnL+o1HCS90LmbHzE5dzMiG1iRgDcaLUzCcC0YYtEOcToqO +Z24njoktTAOmlIaBi2mjfbjho+MlyWOPjXq1LrG0PQ24uKa7AN8TiQl6PVGqqSoR/skQEPk rhN+XtWNf5zpOBtTB9FNSSkOMhNlpuyl/I5BQa1bB3XwhHiCth8brqGrF0H6Daxh4Vqkpfvz SkaywzMI2raUKnuQkj7WXLX7ttCKOA920P9uRTKoQqLgD5lka3uqNUqEBvTDhJUhToXWhMvq ePI2rDNLBVPIh6gUiWzPBnwTInjozCA4R9CW0rMsjeV1BrK1/XjVYtjnZfALWIvYzeXHvP1E rg20xopFwtQKsprdaQE9fzga8ivUywnaP8jIijzMoAWDdjePdyNoFzNo46GJGVppAlRdc+hY eAUetcPHwGwoiLfegj34vaPHvP1Ho4ewj3E4FzTK5kFNAgHBv/izFAotPnAkphMcY9C2QoEc gOLABwyDWN7O9lUDA6tWDWjcNI4Eq78KracxG1ryVXglb1H3NCELQVxttrWsIpMgYDVVzQ/u 5AStXTGR+84B1Fpyo/j5FpjEe50Jq8BDFVrc4eb8+b6j0aPJxmdDe5wzcAHVojbEcmiHUacS oAwb8kroBwzaQbxqd6AmFRxVoXraI6jG77wQaMlmzuJHw7BBG+6FYQLx92HO0IZAb4mJ2CHo 8Sxo0+x977BgykASDSV7lprpzHXUpQ+zCYYpsAuxrPc1PuzKhlZCf/sQFiD/riq1f4KWHhUp /CAzPSMjIy1NtIHWpEIrKsyz7cy+eUH9sD1BK+HPro3QsjMEMxzL30bJRPblbk7QFn3jNtvj Hl/OI+tZ0LYjrUs35pGEZkO7jWufCbCdHh9nv4WuEEbQFuVfJnxYMp+RoO1iYi+dgrbsS1Qj IHQu6XHphY1rb+jKX2DZs2EiOTbzmH6YkbNCvlWpWCh7PIj5BE+HNoVSiwL+7GOWWhTV+Qmc SKLqCw+otOgGTCG/D5+q2sgG2nwu6XTvfBUaB+UELQ5x2m7WYPLj0C4l6WSfFblftdBJVp/h bEqQ+UxvEuYyf/+kyKL4qWp78+Ustf3ga/Z4rUMX4VnQ1gY2XoltZqOQB0B3PbtXpXgo2e3/ sVHX6UJV7xG0jsuYG7XGvgeLeCl7jFVtDMxm94569SiUL03J27nXx2ajNkHprSkZWWnnmlcg 377GRSl9uxfUJ5jeg5MM2vbsoz61gH2ZdxF0vmnMXA3+KUb8lLQrh3YDLGH1TYBmlKY/QZtR 1mODmH6hBujucqcUe/eJSs3KzFgO1SLwHRifpb83ANhnYGM9PddlZWTGHMli41pVIbeEz4yZ sZ2AhXjeZy4cQVtKhfZdBu0110K/ZGSkJx/93kTQDuTQeviYTLgNhiSZ9AaFPNO21w2ZG6HM I7VjRZaAyffTs9Jjp0C8XM59vZgeVhOArP4RmEjQVuDQzuce8nkodjRLf9aXxbxc5f2GQ9uI QxvIoD1AYxV2MkKG4cEw4CZAhbYv2M1PMSaMoN4iJ5SF9ZmGG+3JU0fRHsofy8wKqcDG+8EA raMNWTugRAL/EnoQkPMi44uRWo7t9jJ23lVqFAGfcZgxBlwC/Hxmm6X2D7OHLJAGY9CmDAeP wBLgR34kSe0ui9QuspXaszRAcdGVrQUTKoAZ2qGgKxhYvYCu/AHEsPJQsI5Lp94kJTL+Vgry 1fKHgXqCtpHKyJNFoUgdh/7tVGiDGLSKVWpPkmAcLg0Fawb4wHtMIfez2FoJb7eD0vVrtaQh 2lhwDywJZX9nXGNZRjRxcqhQs7yDW5N03OaiK1MLxvsxaNU55HLwiKCdS/UREFd72ftWdHT7 VlZspbYBtY9J7QOFT1ko4ZWhQB33toMek9oppYpV94Iu99kaQlkoGegO49hQHoqP1wX6Obgs IeE8B+17OtQsAcUPsKqJuJF9tVB5UdByRZmwanBQyz5fRbIPfa/q1HLwicxao6nRX/nR2DMh 4GM+LqvDPsejCD8NbPn2nAcsAm592ZPqVOyhUrtZC1OqfUhp5laKJNV3uH9Ql9U4ol6iKjcZ h2b1bhnU/9u7LEHEuFZtPzVuLn2CXcTPeadF11mUJLX6B+oMMF4Y0ar9PGVJhcuIiYE0rKL6 9WrOof2iahSbv0la2LtFu5EbExWM9Z3Hn3d4m/xojJ3TpVnD9pSruG9wUMdZd9HyxROU9o5r 37zr5GOkyJXfBwR1WYmj6iZQSWVWsg+oN2XnKG0tfVx1/j9s13ZMKCvtpt9ctUZpNcbSDwGH NExSMKTMOmpyzEetW0/N3FPyN3MYkgEHQ1jMiBadl6fxCM87szoGDd7P8pOhAm7uGjTkGDM2 F2jQ+EW71h9FqjES+Id3Q3xx0KpfGTXzQLQc+5XzEU2WSf1nf3jXunogPXGUKhVkniZX1wWU Jz7iopgnxp72dRclhzS2dbMWn90I9TQx/kNUnlK1bFZkLw88a7+BTRuss1EnVBdctgmVYnE0 UEaR1CIZtIN4tKFaDJu12vsioeWVFExGGvnzACeBH8ln4J8i1jONZuCfjTcZzFFV7EW+4iHq JXXdQtKrATM2afhbahq1zwhGazqZHcun8NQstIbfVyzFsLE1PRfoubVsGqAZeDUFg2xNY2KR ObJePanBaORcpfsGoxqCpBaWvTWCtc/ED3OTrFWj5AxzI6+lpTWSeiQhWjJHxVoLSqOY06ht kPSWVS4D2ZwzyHI2g8q4yEVehopoLpsNuYeh3sAOJSTZvntiTf6qWXm+B0DbG5W3ZJHaHAQc ylgm+5jUDrbECJvIutv7vYC4KQ3avCUJQ1Y/yhFaZeu+7Bns5FUhlhhhCcNX/Rz1AoI8NWhf BnqazdegfblAEnJGSRHEbKlVBCn7QhbEF4CsBu3rSxq0GrQaadBqpEGrkQatRhq0GmnQatBq pEGrkQatRhq0GmnQaqRBq0GrkQatRhq0GmnQaqRBq5EGrQatRhq0GmnQaqRBq5EGrUYatBpp 0GrQaqRBq5EGrUYatBpp0GqkQatBq5EGrUYatBr96/R/DxKVeiXSZJAAAABKdEVYdHNpZ25h dHVyZQAyZWM1NjM0OGFjOGM1MzIxNGE2NGU3NDdmMDMyOTZmZmMyYTZkYzU5NzUxY2E3OGQx NWNhOTU2MDFhYjUyY2Y1+FwpPQAAAABJRU5ErkJggg== --w8hSrnmDTh-- From MAILER-DAEMON Fri Nov 28 18:22:09 2014 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuUrZ-0006RF-Si for mharc-bug-texinfo@gnu.org; Fri, 28 Nov 2014 18:22:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuUrS-0006QC-GO for bug-texinfo@gnu.org; Fri, 28 Nov 2014 18:22:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuUrI-0004Ps-SY for bug-texinfo@gnu.org; Fri, 28 Nov 2014 18:22:02 -0500 Received: from frenzy.freefriends.org ([66.54.153.139]:44585 helo=freefriends.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuUrI-0004Ph-MY for bug-texinfo@gnu.org; Fri, 28 Nov 2014 18:21:52 -0500 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.14.9/8.14.9) with ESMTP id sASNLhuh019471; Fri, 28 Nov 2014 16:21:44 -0700 Received: (from nobody@localhost) by freefriends.org (8.14.9/8.14.9/submit) id sASNLhRk019469; Fri, 28 Nov 2014 23:21:43 GMT Date: Fri, 28 Nov 2014 23:21:43 GMT Message-Id: <201411282321.sASNLhRk019469@freefriends.org> X-Authentication-Warning: frenzy.freefriends.org: nobody set sender to karl@freefriends.org using -f From: karl@freefriends.org (Karl Berry) To: per@bothner.com Subject: Re: real subscripts and superscripts? In-Reply-To: <5478CE6B.4020401@bothner.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 66.54.153.139 Cc: bug-texinfo@gnu.org X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 23:22:08 -0000 I want some sane way of writing i^2 and R^4 so I get tolerably-looking expressions with superscripts in both TeX andDocBook/HTML. Sure. First, with non-letter superscripts (numbers, +, etc.), you're fine with the present @sup inside math, regardless of whether @sub/@sup mean text inside math for TeX, because numbers are typeset by TeX in roman, not math italic, in any case. makeinfo presently outputs @math as ..., which results in italic sub/superscripts inside @math (as well as everything else), regardless of their content. That's inconsistent with TeX, but I think it's expected and reasonable for HTML. Implementing ^_ in makeinfo would allow for better matching of input/output, i.e., allowing documents to use ^_ inside @math and get the expected output. I think that's desirable for its own sake, separate from any question of @sub and @sup. Anyway, it's alphabetic sub/superscripts where the question of whether @sub/@sup means "text" inside math makes a difference to TeX (nothing else). I'll await Patrice's comments before finalizing the TeX versions and documentation. I don't feel that strongly about it. karl