Thread: [MiKTeX] beta 7: yap: file argument
MiKTeX source code moved to GitHub
Brought to you by:
csc
From: Stephan H. <mai...@ar...> - 2006-05-16 14:49:44
|
Hi, when running yap from command line and giving as argument a file with path information that path information isn't interpreted correctly. E.g., issuing the command > yap c:\home\latex\somefile.dvi results in a message window popping up complaining > No such file or directory: C:\homelatexsomefile.dvi > > Data: > C:\homelatexsomefile.dvi Regards, Stephan Hennig |
From: Stephan H. <mai...@ar...> - 2006-05-27 18:29:58
|
Stephan Hennig schrieb: > when running yap from command line and giving as argument a file with > path information that path information isn't interpreted correctly. > E.g., issuing the command > >> yap c:\home\latex\somefile.dvi > > results in a message window popping up complaining > > >> No such file or directory: C:\homelatexsomefile.dvi >> >> Data: >> C:\homelatexsomefile.dvi Still present in Beta 8. However, manually doubling all backslashes works, i.e., > yap c:\\home\\latex\\somefile.dvi But this is no workaround since it's hard to tell editors such insane syntax. Regards, Stephan Hennig |
From: Christian S. <cs...@mi...> - 2006-05-27 18:36:36
|
Stephan Hennig wrote: > Still present in Beta 8. However, manually doubling all backslashes > works, i.e., > >> yap c:\\home\\latex\\somefile.dvi > > But this is no workaround since it's hard to tell editors such insane > syntax. It will be fixed in Beta 9. |
From: Stephan H. <mai...@ar...> - 2006-05-28 10:18:04
|
Christian Schenk schrieb: > Stephan Hennig wrote: >> Still present in Beta 8. However, manually doubling all backslashes >> works, i.e., > > It will be fixed in Beta 9. Thanks! I'm looking forward to it. Except for that bug MiKTeX 2.5 looks good to me. I'm considering returning completely to dvi format for document preparation. Regards, Stephan Hennig |
From: Stephan H. <mai...@ar...> - 2006-05-28 17:14:25
|
Stephan Hennig schrieb: > I'm considering returning completely to dvi format for document > preparation. If only Yap's background color were configurable, see this feature request <URL:http://sourceforge.net/tracker/index.php?func=detail&aid=1025332&group_id=10783&atid=360783>. Regards, Stephan Hennig |
From: Christian S. <cs...@mi...> - 2006-05-28 17:48:51
|
Stephan Hennig wrote: > If only Yap's background color were configurable, see this feature request > <URL:http://sourceforge.net/tracker/index.php?func=detail&aid=1025332&group_id=10783&atid=360783>. I must admit that I have never understood this request because a) paper is white in most cases b) paper color should be set per-document (like paper size) |
From: Stephan H. <mai...@ar...> - 2006-05-28 21:00:37
|
Christian Schenk schrieb: > Stephan Hennig wrote: >> If only Yap's background color were configurable, see this feature request >> <URL:http://sourceforge.net/tracker/index.php?func=detail&aid=1025332&group_id=10783&atid=360783>. > > I must admit that I have never understood this request because > > a) paper is white in most cases But there is not "the one white". Tschichold, Willberg and other typographers often complain about paper manufacturers for there blinding white papers. Contrast is much too strong with dark (black) letters on them. Typographers in general prefer shaded colors, e.g., broken white, ivory or something else -- sorry for my bad terminology -- with much less contrast. Blinding white paper hurts the eyes without improving legibility. Have a look into your favorite novel book or other non scientific literature. Is it blinding white paper? I'd bet, that not. Why does this count for screen reading? Screen is an active light emitter while paper is only reflecting light. Therefore, screen light is even more uncomfortable to look at than blinding white paper. I'm quite comfortable with a background color of #fff8e9 throughout all my applications. Just try it for two days and then switch back. Hell! > b) paper color should be set per-document (like paper size) Since I won't print paper color -- Would you? -- I don't think it should be a document property. The one exception I see are screen presentations (where one would likely suppress background colors for printed handouts). Additionally, there is no one to one relation between a viewer (an application) and a document. A viewer is /a tool/ that I use if it eases my task of document preparation /on a computer/. Visually disabled people might prefer an inverted color set to view documents on screen. Even if they wouldn't print documents white on black. I (and perhaps others) like some shaded white. Respecting user's preferences in this matter would be a very valuable feature for Yap. Regards, Stephan Hennig |
From: Wenchang S. <wen...@un...> - 2006-07-23 06:58:28
|
Dear All, A space is omitted between the tfm name and the encoding name unless the encoding is "default". As a result, the according maplines are illegal. |