manual typos and formatting inconsistencies #886
Conversation
…mple in `pgfmanual-en-tikz-graphs.tex` work closes issue pgf-tikz#755)
| @@ -66,7 +66,7 @@ \subsection{Declaring an Image} | |||
| \begin{command}{\pgfdeclareimage\oarg{options}\marg{image name}\marg{filename}} | |||
| Declares an image, but does not paint anything. To draw the image, use | |||
| |\pgfuseimage{|\meta{image name}|}|. The \meta{filename} may not have an | |||
| extension. For \textsc{pdf}, the extensions |.pdf|, |.jpg|, and |.png| | |||
| extension. For \textsc{pdf}, the extensions |.pdf|, |.jpg|, and |.png| | |||
There was a problem hiding this comment.
| extension. For \textsc{pdf}, the extensions |.pdf|, |.jpg|, and |.png| | |
| extension. For \textsc{pdf}, the extensions |.pdf|, |.jpg|, and |.png| |
This is the correct way to space sentences, see e.g. Wikipedia. Also good text editors like Emacs or Vim have shortcuts to navigate sentences and therefore need two spaces to distinguish the end of a sentence from the space after “e.g.“ or “i.e.”.
Please revert this and all other similar changes.
There was a problem hiding this comment.
In the stated Wikipedia article there isn't stated that this is the correct way to space sentences. Rather there seems to be opposing opinions and for the newer age it seems to tend to using on space. But that is not the point here because in LaTeX we can decide what we want to see in the output and has nothing to do with the spaces in the input. (I think we agree on that.)
But of course that editors use them is a very relevant point, especially when the main contributor to this project uses one of them ;)
I know that you stated that point in the past already and we agreed that I will not touch any of the "two spaces" you have written (for the above reason). And I am pretty sure that I haven't.
So just for clarity: If you insist to revert that changes I will do it. But I just want to mention my point again which is consistency. In the given example above there are two more sentences before the one that is diffed and there is only given 1 space after the end-of-sentence-dot.
So could you live with the current pull request or shall I change it as you wish? (Please note that this was a one-time-search for the two spaces and thus will not happen again.)
There was a problem hiding this comment.
I was waiting for your answer which is still lacking. But I'll take it as "you still wish that I revert the end-of-sentence-dots".
Below I asked another question which is also not answered yet. Could you please let me know your opinion, too, so I don't do unnecessary/double work. Thank you very much in advance.
|
@hmenke, any opinions on the other points I want to change in the manual as stated in the first comment in this pull request? |
|
4 should definitely be addressed. |
In a previous commit (hopefully) all remaining instances of two consecutive spaces were removed. Henri *insists* that the ones after an end-of-sentence dot should stay, although the rest of the manual reveals another style chosen by the original author(s). Therefore change 12 instances back to two spaces.
which somehow sneaked in when resolving conflicts with the GitHub tool.
This cherry-picks the usable part of PR #886
|
Cherry-picked into 9ac32f1 |
So far fixed some typos and removed double/multiple spaces.
Things that still can be done to harmonize/correct stuff in manual:
behaviorvs.behaviour--> I prefer US spellingsection~<-->Section~--> most of the\refprefixes use the latter, so I'd harmonize to that$x$ coordinate<-->$x$-coordinate\emph{Note:\/}<-->\emph{Note:}Mineral\"olprodukte--> replace by UTF-8 character -->MineralölprodukteAre there any opinions/arguments against that proposed changes? If not, I would apply them one by one.