You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(27) |
Jun
(22) |
Jul
(72) |
Aug
(82) |
Sep
(86) |
Oct
(138) |
Nov
(100) |
Dec
(62) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(122) |
Feb
(147) |
Mar
(92) |
Apr
(82) |
May
(101) |
Jun
(153) |
Jul
(37) |
Aug
(34) |
Sep
(46) |
Oct
(46) |
Nov
(6) |
Dec
(38) |
2004 |
Jan
(64) |
Feb
(81) |
Mar
(36) |
Apr
(194) |
May
(329) |
Jun
(272) |
Jul
(68) |
Aug
(74) |
Sep
(150) |
Oct
(57) |
Nov
(62) |
Dec
(63) |
2005 |
Jan
(78) |
Feb
(30) |
Mar
(137) |
Apr
(78) |
May
(54) |
Jun
(122) |
Jul
(72) |
Aug
(110) |
Sep
(80) |
Oct
(75) |
Nov
(125) |
Dec
(79) |
2006 |
Jan
(100) |
Feb
(15) |
Mar
(41) |
Apr
(67) |
May
(30) |
Jun
(11) |
Jul
(14) |
Aug
(22) |
Sep
(20) |
Oct
(14) |
Nov
(11) |
Dec
(15) |
2007 |
Jan
(17) |
Feb
(16) |
Mar
(35) |
Apr
(21) |
May
(33) |
Jun
(50) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
2008 |
Jan
(14) |
Feb
(20) |
Mar
(35) |
Apr
(9) |
May
(57) |
Jun
(21) |
Jul
(42) |
Aug
(4) |
Sep
(13) |
Oct
(76) |
Nov
(40) |
Dec
(55) |
2009 |
Jan
(26) |
Feb
(15) |
Mar
(3) |
Apr
(67) |
May
(32) |
Jun
(39) |
Jul
(59) |
Aug
(31) |
Sep
(59) |
Oct
(64) |
Nov
(21) |
Dec
(10) |
2010 |
Jan
(21) |
Feb
(3) |
Mar
(116) |
Apr
(33) |
May
(9) |
Jun
(28) |
Jul
(21) |
Aug
(23) |
Sep
(146) |
Oct
(70) |
Nov
(31) |
Dec
(57) |
2011 |
Jan
(33) |
Feb
(22) |
Mar
(11) |
Apr
(21) |
May
(51) |
Jun
(47) |
Jul
(35) |
Aug
(26) |
Sep
(25) |
Oct
(34) |
Nov
(61) |
Dec
(51) |
2012 |
Jan
(75) |
Feb
(31) |
Mar
(26) |
Apr
(16) |
May
(24) |
Jun
(24) |
Jul
(31) |
Aug
(46) |
Sep
(36) |
Oct
(28) |
Nov
(37) |
Dec
(21) |
2013 |
Jan
(16) |
Feb
(56) |
Mar
(31) |
Apr
(44) |
May
(45) |
Jun
(29) |
Jul
(38) |
Aug
(18) |
Sep
(12) |
Oct
(16) |
Nov
(21) |
Dec
(11) |
2014 |
Jan
(13) |
Feb
(14) |
Mar
(28) |
Apr
(7) |
May
(72) |
Jun
(33) |
Jul
(21) |
Aug
(1) |
Sep
(6) |
Oct
(14) |
Nov
(18) |
Dec
(22) |
2015 |
Jan
(23) |
Feb
(108) |
Mar
(76) |
Apr
(114) |
May
(60) |
Jun
(9) |
Jul
(8) |
Aug
(9) |
Sep
(42) |
Oct
(9) |
Nov
|
Dec
(7) |
2016 |
Jan
(6) |
Feb
(15) |
Mar
(7) |
Apr
|
May
(33) |
Jun
(3) |
Jul
(19) |
Aug
(12) |
Sep
(6) |
Oct
(16) |
Nov
(17) |
Dec
(125) |
2017 |
Jan
(66) |
Feb
(98) |
Mar
(29) |
Apr
(32) |
May
(63) |
Jun
(98) |
Jul
(26) |
Aug
(33) |
Sep
(19) |
Oct
(77) |
Nov
(31) |
Dec
(27) |
2018 |
Jan
(32) |
Feb
(11) |
Mar
(5) |
Apr
(12) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(13) |
Sep
(11) |
Oct
(6) |
Nov
(23) |
Dec
(2) |
2019 |
Jan
(26) |
Feb
(12) |
Mar
(20) |
Apr
(18) |
May
(7) |
Jun
(22) |
Jul
(81) |
Aug
(129) |
Sep
(32) |
Oct
(18) |
Nov
(11) |
Dec
(44) |
2020 |
Jan
(19) |
Feb
(10) |
Mar
(38) |
Apr
(4) |
May
(9) |
Jun
(15) |
Jul
(29) |
Aug
(79) |
Sep
(12) |
Oct
(22) |
Nov
(10) |
Dec
(37) |
2021 |
Jan
(16) |
Feb
(14) |
Mar
(20) |
Apr
(100) |
May
(21) |
Jun
(19) |
Jul
(13) |
Aug
(13) |
Sep
(37) |
Oct
(112) |
Nov
(64) |
Dec
(22) |
2022 |
Jan
(209) |
Feb
(38) |
Mar
(11) |
Apr
(10) |
May
(55) |
Jun
(104) |
Jul
(35) |
Aug
(10) |
Sep
(21) |
Oct
(21) |
Nov
(50) |
Dec
(12) |
2023 |
Jan
(6) |
Feb
|
Mar
(3) |
Apr
(41) |
May
(48) |
Jun
(9) |
Jul
(6) |
Aug
(25) |
Sep
(3) |
Oct
(22) |
Nov
(56) |
Dec
(12) |
2024 |
Jan
(5) |
Feb
(5) |
Mar
(38) |
Apr
(62) |
May
(12) |
Jun
(10) |
Jul
(3) |
Aug
(59) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: David G. <go...@py...> - 2004-05-03 22:06:00
|
David Abrahams wrote: > The second time I try to use a doubly-indirected substitution > reference, the HTML writer croaks (it works if I only try once). Yup, looks like a bug. I'll add it to the to-do list. Did this come up in an actual document? I'd be interested to know why you'd ever need doubly-indirect substitutions. -- David Goodger |
From: David A. <da...@bo...> - 2004-05-03 18:40:08
|
-- |
From: Edward L. <ed...@gr...> - 2004-05-01 03:52:16
|
[David said:] > I agree with Fred; em/en aren't needed. Being so subjective, they'd > be too difficult to handle anyhow. Another reason not to use em/en (not that we need another): "em" means different things in LaTeX and HTML. In LaTeX, it's the width of a capital "M" in the current font. In HTML, it's the total height of the font, including any descenders, diacritics, etc. -Edward |
From: David G. <go...@py...> - 2004-05-01 01:23:58
|
Felix Wiemann wrote: >> Could you elaborate, with an example perhaps? > > <img style="width: 12in; height: 8in;" src="image.png" alt="" /> > > See <http://www.htmlhelp.com/reference/css/units.html#length>. Thanks for jogging my memory (I *think* I once knew about this ;-). It's also covered in the CSS1 spec: <http://www.w3.org/TR/REC-CSS1#length-units>. -- David Goodger |
From: David P. <pr...@sf...> - 2004-04-30 23:47:34
|
On Fri, 30 Apr 2004 18:37:12 -0400, David Goodger <go...@py...> wrote: > __ `named destination`_ > __ http://example.org/URI > > If you get rid of the whitespace and require backquotes, it becomes > very difficult to tell the difference. Well, heck. Again, you are right. It's a damn good thing you're project lead! :-) |
From: Felix W. <Fel...@gm...> - 2004-04-30 23:14:11
|
David Goodger wrote: >>> * How should the HTML writer handle units *other* than pixels? >> >> CSS. > > Could you elaborate, with an example perhaps? <img style="width: 12in; height: 8in;" src="image.png" alt="" /> See <http://www.htmlhelp.com/reference/css/units.html#length>. -- When replying to my email address, ensure that the mail header contains 'Felix Wiemann'. Please don't send unrequested mails > 64 KB. <http://www.ososo.de/> |
From: David G. <go...@py...> - 2004-04-30 22:37:23
|
David Priest wrote: > What is a URI but the name of something? There is no *need* to > quote URIs but consistency in markup would require the ability to do > so. There's a need *not* to quote URIs. If we quote URIs, how do we differentiate between a _`named destination` and a _`http://example.org/URI`? Currently, they look different. Here are two anonymous targets: __ `named destination`_ __ http://example.org/URI If you get rid of the whitespace and require backquotes, it becomes very difficult to tell the difference. We can't rely on URI schemes (the "http:" part) because: __ this_is_a_relative_URI > I'm going to be radical and suggest that *all* links, no matter how > short, be quoted. I'm going to be blunt and say no. I hope my counterexample above convinced you. If it didn't, that's just because I'm unable to express the rationale clearly enough. In any case, this particular syntax is not going to change now. Orthogonality is important and useful, but being able to differentiate between different cases is more important. -- David Goodger |
From: David P. <pr...@sf...> - 2004-04-30 21:38:37
|
On Fri, 30 Apr 2004 17:16:22 -0400, David Goodger <go...@py...> wrote: > Now my rationale: > > In none of the cases above are URIs alone ever quoted, only names. > There's no need to quote the URI in a named or anonymous target: > > .. _name: http://example.org > __ http://example.org > > There's no precedent, so there's no orthogonality. What is a URI but the name of something? There is no *need* to quote URIs but consistency in markup would require the ability to do so. I'm going to be radical and suggest that *all* links, no matter how short, be quoted. The backtick serves as an indicator to the reader that the next bit of text is somehow special. In that regard it operates a bit like the upside-down question mark used in Spanish, which precedes the sentence so that you know it's a question long before you get to the end of it and have to rethink your understanding of what you just read. I'm not going to argue comprehensively about this, because what we have now works "good enough." I do find it jarring to not be able to apply my knowledge of `links`_, which I use all the time in text (especially as links to a section title) to the use of _`destinations`. |
From: David G. <go...@py...> - 2004-04-30 21:26:33
|
Adam Chodorowski wrote: > It seems that it's not possible to use the `include` directive with > filenames that contain whitespace:: > > index.txt:5: (ERROR/3) "Include" directive path contains > whitespace. > > Escaping the whitespace with ``\`` doesn't help. Am I missing > something, or is this a deficiency in docutils right now? I'd thought it was a feature, but perhaps I was wrong. I should've known better, coming from a Mac OS background. ;-) Another to-do item. -- David Goodger |
From: David G. <go...@py...> - 2004-04-30 21:26:18
|
Fred L. Drake, Jr. wrote: >> I agree with Fred; em/en aren't needed. Being so subjective, >> they'd be too difficult to handle anyhow. > > I didn't say they were subjective! No, I did. ;-) Perhaps I should have said "indirect and complicated to evaluate", since they'd require knowledge that Docutils cannot hope to have. Em/en might be useful for some output formats, but I can't imagine trying to implement them for HTML. But I've been wrong before, and I'm sure to be wrong again. -- David Goodger |
From: David G. <go...@py...> - 2004-04-30 21:16:31
|
David Priest wrote: > Why wasn't that (__`url:`) appropriate? Some background first. The trailing underscore is used to indicate a named hyperlink reference: a reference name_ Backquotes are used for phrase references, or to disambiguate: a `phrase reference`_ and a `name`_ The backqoutes quote the reference name. Inline targets use a leading underscore (think of an underscore as a right-pointing arrow, "->"). an _`inline target` Inline targets require the backquotes to quote the target name because leading underscores are too common in technical language (like "_variable"). Now my rationale: In none of the cases above are URIs alone ever quoted, only names. There's no need to quote the URI in a named or anonymous target: .. _name: http://example.org __ http://example.org There's no precedent, so there's no orthogonality. ***** I feel there's a need to explain my obstinacy here and in other recent cases. I consider the established reStructuredText syntax to be pretty mature. I am loathe to change the syntax, because any change would imply breakage. It would take an *extremely* convincing and objective argument to make me even consider changing the syntax. So be warned, any syntax change proposals will require an active champion who had better be prepared to defend their proposal vigorously. There are places where we can still *add* syntax, like "|" for line blocks and "_" for targets, both recently proposed. Adding syntax shouldn't break existing documents, so it's much easier to do. But removing or changing syntax is much harder, requiring the initial syntax to be well thought out, which takes time. ***** > Wanna see a large PDF that's being autogenerated from > RST->DocUtils->XSL:FO->XEP->PDF? Sure. > This system is working so incredibly well. Glad to hear it! -- David Goodger |
From: Fred L. D. Jr. <fd...@ac...> - 2004-04-30 21:10:19
|
On Friday 30 April 2004 08:53 am, David Goodger wrote: > - Tack the units onto the height/width values? > (Would the units of both height & width have to match?) This is the way to go. > I agree with Fred; em/en aren't needed. Being so subjective, they'd > be too difficult to handle anyhow. I didn't say they were subjective! They *might* even make sense for images embedded inline with text, but they only make sense when there's a clear and specific association with text, because the actual size can only be computed from the font metrics. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
From: Brent C. <bus...@ya...> - 2004-04-30 20:34:29
|
On Fri, 30 Apr 2004, David Goodger wrote: > David Priest wrote (off-list; quoting with permission): > > On Fri, 30 Apr 2004 08:53:46 -0400, David Goodger <go...@py...> > > wrote: > > > >> Problem: "scale" is already treated as a percentage, without a "%". > >> You're assigning a different meaning to the word "scale". Perhaps > >> "resolution" instead? Is there a better, more precise term > >> ("pixels-per-unit")? > > > > If we're held back by legacy support requirements, then: > > :scale: > > - blank = percentage > > - % = percentage > > - in = inches > > - cm = centimeters > > - px = pixels > > - dpi = resolution > > I don't understand. "Scale" here means reduce/enlarge by a > percentage. What would ":scale: 3in" mean? > > Some writers will be fine with ":width: 3in" as-is, but HTML needs > pixels, so to convert inches to pixels it needs to know the resolution > of the image: how many pixels per inch or centimeter or point. > > Perhaps a ":resolution: 300px/in" option? Don't some image formats > know their own resolution? Perhaps we could use PIL to find out if > nothing is specified. > The HTML writer already uses PIL to determine image size in pixels and writes derived height and width attributes when scale is specified, scaling by pixel %age. - Brent |
From: Adam C. <ad...@ch...> - 2004-04-30 20:34:28
|
Hi. It seems that it's not possible to use the `include` directive with filenames that contain whitespace:: index.txt:5: (ERROR/3) "Include" directive path contains whitespace. Escaping the whitespace with ``\`` doesn't help. Am I missing something, or is this a deficiency in docutils right now? -- Adam Chodorowski <ad...@ch...> Coward, n.: One who in a perilous emergency thinks with his legs. -- Ambrose Bierce, "The Devil's Dictionary" |
From: David P. <pr...@sf...> - 2004-04-30 20:28:18
|
On Fri, 30 Apr 2004 16:16:49 -0400, David Goodger <go...@py...> wrote: > I don't understand. "Scale" here means reduce/enlarge by a > percentage. What would ":scale: 3in" mean? It'd be meaningless. So much for that idea. > Some writers will be fine with ":width: 3in" as-is, but HTML needs > pixels, so to convert inches to pixels it needs to know the resolution > of the image: how many pixels per inch or centimeter or point. That's when you'd need to use the scale for dpi, perhaps. Given an inch width and a dpi scale, it can calculate the pixel width. > > Nice orthogonality that way. *Very* important, is orthogonality. > > Yes, but only when appropriate. This isn't. Why wasn't that (__`url:`) appropriate? It makes the markup more orthogonal, which makes it easier to remember, and it doesn't make it more difficult to read. What important appropriateness-rule is it breaking? Thanks for adding multiple classes. There are a few cases where that will make my XSL:FO much, *MUCH* easier. Wanna see a large PDF that's being autogenerated from RST->DocUtils->XSL:FO->XEP->PDF? This system is working so incredibly well. |
From: David G. <go...@py...> - 2004-04-30 20:19:29
|
[David Goodger] >> * How should the HTML writer handle units *other* than pixels? [Felix Wiemann] > CSS. Could you elaborate, with an example perhaps? -- David Goodger |
From: David G. <go...@py...> - 2004-04-30 20:17:00
|
David Priest wrote (off-list; quoting with permission): > On Fri, 30 Apr 2004 08:53:46 -0400, David Goodger <go...@py...> > wrote: > >> Problem: "scale" is already treated as a percentage, without a "%". >> You're assigning a different meaning to the word "scale". Perhaps >> "resolution" instead? Is there a better, more precise term >> ("pixels-per-unit")? > > If we're held back by legacy support requirements, then: > :scale: > - blank = percentage > - % = percentage > - in = inches > - cm = centimeters > - px = pixels > - dpi = resolution I don't understand. "Scale" here means reduce/enlarge by a percentage. What would ":scale: 3in" mean? Some writers will be fine with ":width: 3in" as-is, but HTML needs pixels, so to convert inches to pixels it needs to know the resolution of the image: how many pixels per inch or centimeter or point. Perhaps a ":resolution: 300px/in" option? Don't some image formats know their own resolution? Perhaps we could use PIL to find out if nothing is specified. > Another issue: > > .. class: `knights grail bunny` > > Results in an error message. Yet in the world of XML and CSS2, it > isn't uncommmon to `assign multiple classes`__ to a single tag. That's true. I'll add support for multiple classes to the to-do list. > To match a subset of "class" values, each value must be preceded > by a ".", in any order. > > For example, the following rule matches any P element whose > "class" attribute has been assigned a list of space-separated values > that includes "pastoral" and "marine": > > p.pastoral.marine { color: green } > > This rule matches when class="pastoral blue aqua marine" but > does not match for class="pastoral blue". > > The fix is easy: allow more than one class argument, leaving spaces > as spaces. > > __`http://www.w3.org/TR/CSS21/selector.html#class-html` > > Also, I don't know if what I just did there for the anonymous link > is correct, No, it should have been this: __ http://www.w3.org/TR/CSS21/selector.html#class-html > but it should be. It exactly mirrors the convention for specifying > a link inline I don't think so. For one thing, it's a URI, and URIs never need quoting, whether inline or standalone. > Nice orthogonality that way. *Very* important, is orthogonality. Yes, but only when appropriate. This isn't. > I wish all email clients supported RST. It'd look so good. :-) -- David Goodger |
From: Felix W. <Fel...@gm...> - 2004-04-30 18:52:30
|
David Goodger schrieb: > David Priest wrote: > >> I'd like to suggest that DocUtils be a bit more flexible in its field >> parsing for the width and height components of the image & figure >> directives. Let's let us specify a unit measure. I'd only like it if it's easy to implement, because otherwise, it makes writing new writers difficult and bloats the code. > So, how to implement it? > > * Modify the "image" & "figure" directives: > > - New "unit" option that applies to both height & width? Too clumsy. > - Tack the units onto the height/width values? Yes. > (Would the units of both height & width have to match?) I don't see any reason for that. > * How should the HTML writer handle units *other* than pixels? CSS. -- When replying to my email address, ensure that the mail header contains 'Felix Wiemann'. Please don't send unrequested mails > 64 KB. <http://www.ososo.de/> |
From: Beni C. <cb...@us...> - 2004-04-30 14:59:42
|
[Resending as first message seems to have been lost (I know, I replied to David only by mistake, I also sent a copy to the list). Sorry if it gets duplicated.] David Goodger wrote: > [Moved from docutils-users] > > Beni Cherniavsky wrote: >> The ``.. _name: target`` syntax is awkward. The fact that the >> underscore is adjacent to the name, even if it consists of many >> words, is inconsistent, > > Inconsistent how? > Slightly inconsistent in allowing the underscore to be adjacent to the word while applying to many words.Depends on how you quint at it :-). >> visually unbalanced IMHO (it looks to me as if the underscore > > attaches to the first word only) > > You can also write it like this: > > .. _`name`: target > .. _`long name with many words`: target > I forgot this form was possible.Perhaps I'll even use it... > Leaving off the backquotes is a convenience. > ...and perhaps not <wink>. >> and creates problems while editing (I committed a fix for emacs' >> rst-mode but the world is full of less intelligent editors). >> >> For anonymous links, we already have the very convenient ``__ >> target`` shorthand syntax for ``.. __: target``. I'm sometimes >> tempted to use anonymous links where named links are due only >> because they have a nicer syntax. So I propose to add ``_ name: >> target`` as a shorthand for ``.. _name: target``.What do you >> think? > > It's an interesting proposal.I'd like to hear others' opinions. > >> I'm ready implement it if it's approved. > > -- David Goodger > -- Beni Cherniavsky <cb...@us...> |
From: David G. <go...@py...> - 2004-04-30 13:43:10
|
Felix Wiemann wrote: > Well, IMO the problem is that it isn't clear if examples.py can be > relied upon, concerning compatibility in future releases. Thanks for the explanation. > I.e., can a developer simply include the module and use the > functions, being reasonable confident that neither the functions nor > their behaviours will change in the very next release? (Personally, > I'd have a slightly uncomfortable feeling when including a module > called 'examples'. That's why I proposed 'tools'.) > > Or is examples.py what the name says -- just examples, which might be > copied into one's own code? What do people think its role should be? Should it be docutils.examples, useful for copy & paste, or docutils.tools, useful for importing? I've already updated the two functions it contains with new keyword parameters, one at the end but one in the middle. Client code could break if it uses positional arguments instead of keywords. I *think* the interfaces will be stable now, but I could be wrong. ;-) > In either case, it should be documentated IMO. Agreed. -- David Goodger |
From: Felix W. <Fel...@gm...> - 2004-04-30 13:10:12
|
David Goodger schrieb: > Felix Wiemann wrote: > >> [...] what about making a documentated module (e.g. 'tools') of it >> [examples.py]? > > I don't understand. Well, IMO the problem is that it isn't clear if examples.py can be relied upon, concerning compatibility in future releases. I.e., can a developer simply include the module and use the functions, being reasonable confident that neither the functions nor their behaviours will change in the very next release? (Personally, I'd have a slightly uncomfortable feeling when including a module called 'examples'. That's why I proposed 'tools'.) Or is examples.py what the name says -- just examples, which might be copied into one's own code? In either case, it should be documentated IMO. -- When replying to my email address, ensure that the mail header contains 'Felix Wiemann'. Please don't send unrequested mails > 64 KB. <http://www.ososo.de/> |
From: David G. <go...@py...> - 2004-04-30 12:53:57
|
David Priest wrote: > With that in mind, I'd like to suggest that DocUtils be a bit more > flexible in its field parsing for the width and height components of > the image & figure directives. Let's let us specify a unit measure. This has come up before: <http://article.gmane.org/gmane.text.docutils.user/154>. There's a mention of it in the to-do list. I'm for it, but I haven't needed it, therefore *I* haven't implemented it yet. > Even the HTML guys can make use of this, if "scale" is treated as a > %age if it has a % sign, and as dpi if there is no symbol. Problem: "scale" is already treated as a percentage, without a "%". You're assigning a different meaning to the word "scale". Perhaps "resolution" instead? Is there a better, more precise term ("pixels-per-unit")? So, how to implement it? * Modify the "image" & "figure" directives: - New "unit" option that applies to both height & width? - Tack the units onto the height/width values? (Would the units of both height & width have to match?) * How should the HTML writer handle units *other* than pixels? - Require a "resolution" option to convert to pixels? - Or ignore height/width with units without "resolution"? * Issues with other writers? > I don't know whether the units measure should be restricted to > in/cm/pt/px/(blank = px) or whether em/en should also be included. I agree with Fred; em/en aren't needed. Being so subjective, they'd be too difficult to handle anyhow. -- David Goodger |
From: Lele G. <le...@na...> - 2004-04-30 12:28:47
|
>>>>> "David" =3D=3D David Goodger <go...@py...> writes: >> For anonymous links, we already have the very convenient ``__ >> target`` shorthand syntax for ``.. __: target``. I'm sometimes >> tempted to use anonymous links where named links are due only >> because they have a nicer syntax. So I propose to add ``_ >> name: target`` as a shorthand for ``.. _name: target``. What >> do you think? David> It's an interesting proposal. I'd like to hear others' David> opinions. Yes, it seems a good alternative! It stands out very well. For another pros, consider that Emacs dabbrev does not work very well given that initial '_' :-) I'm more and more teaching reST to people, and effectively had some trouble explaining why the syntaxes for a comment and that of target (assuming the latter is used very frequently) are *so* similar... thanx, bye, lele. --=20 nickname: Lele Gaifax | Quando vivr=C3=B2 di quello che ho pensato ieri real: Emanuele Gaifas | comincer=C3=B2 ad aver paura di chi mi copia. email: le...@se... | -- Fortunato Depero, 1929. |
From: Beni C. <cb...@us...> - 2004-04-30 10:11:57
|
David Goodger wrote: > [Moved from docutils-users] > > Beni Cherniavsky wrote: > > The ``.. _name: target`` syntax is awkward. The fact that the > > underscore is adjacent to the name, even if it consists of many > > words, is inconsistent, > > Inconsistent how? > Slightly inconsistent in allowing the underscore to be adjacent to the word while applying to many words. Depends on how you quint at it :-). > > visually unbalanced IMHO (it looks to me as if the underscore > > attaches to the first word only) > > You can also write it like this: > > .. _`name`: target > .. _`long name with many words`: target > I forgot this form was possible. Perhaps I'll even use it... > Leaving off the backquotes is a convenience. > ...and perhaps not <wink>. > > and creates problems while editing (I committed a fix for emacs' > > rst-mode but the world is full of less intelligent editors). > > > > For anonymous links, we already have the very convenient ``__ > > target`` shorthand syntax for ``.. __: target``. I'm sometimes > > tempted to use anonymous links where named links are due only > > because they have a nicer syntax. So I propose to add ``_ name: > > target`` as a shorthand for ``.. _name: target``. What do you > > think? > > It's an interesting proposal. I'd like to hear others' opinions. > > > I'm ready implement it if it's approved. > > -- David Goodger > -- Beni Cherniavsky <cb...@us...> Note: I can only read email on week-ends... |
From: Fred L. D. Jr. <fd...@ac...> - 2004-04-29 18:24:18
|
On Thursday 29 April 2004 01:05 am, David Priest wrote: > With that in mind, I'd like to suggest that DocUtils be a bit more > flexible in its field parsing for the width and height components of the > image & figure directives. Let's let us specify a unit measure. ... > Even the HTML guys can make use of this, if "scale" is treated as a %age > if it has a % sign, and as dpi if there is no symbol. A 3" graphic, with > a scale of 72dpi (Mac World) would be 3x72 pixels wide. +1 > I don't know whether the units measure should be restricted to > in/cm/pt/px/(blank = px) or whether em/en should also be included. I don't see any particular need to em/en to be supported. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |