1b Common questions about dviwin Hippocrates Sendoukas December 1, 1994 This document attempts to answer the most common questions that I received about dviwin; please read this file about any problems, and if you cannot find the answer here, do not hesitate to contact me. My e-mail address is "isendo@leon.nrcps.ariadne-t.gr" and my regular mail address is "3 Sifnou St., Athens 11254, Greece" When I open a dvi file I get only an empty page. Why does this happen? This indicates that the program cannot find any fonts; it usually happens if you did not install any fonts in your hard disk or the base directory specification is incorrect. If you are unsure about the font setup, please read the manual. If you select the "Log" entry in the main menu, you will see the log file where the program indicates which fonts it cannot find. It is always a good idea to check the log file whenever something goes wrong. If you want to know exactly which font files the program is attempting to use, check the "Trace Fonts" entry in the "Options" submenu before opening the dvi file. If you are upgrading from version 2.0, make sure that you change the font directory specification. If for example your base directory is "c:\tex\fonts", you should change it to "c:\tex\fonts\$r". I am sorry for this incompatibility, but the new method is much better. The program finds the fonts, but the letters are too big and on top of each other. This happens when you try to preview at a screen resolution (eg., 100dpi), but you only have fonts for the printer (eg., 300dpi). If dviwin cannot find the correct fonts at 100dpi, it tries all neighboring resolutions until it finds a match. If the matching font is much larger than the requested font, you will end up with overlapping characters, because the positioning is still based at 100dpi. You can find a decent set of screen fonts in the files "dvivga2.zip" through "dvivga8.zip" in the directory pub/msdos/tex of oak.oakland.edu. Unlike the first release of the program, newer versions look only for fonts within three magsteps of the original font resolution, so if you preview at normal screen resolutions but you have only printer fonts, nothing will be displayed. I use a resolution of 100dpi for previewing and my documents display fine. When I try to print however at 300dpi, there are many characters missing. This is probably an indication that you don't have the appropriate fonts at 300dpi. The dvivga fonts are reasonable for screen resolutions, but they are far from complete for printer resolutions; the easiest way to get the required fonts is to do an anonymous login at the CTAN hosts (ftp.shsu.edu, ftp.tex.ac.uk or ftp.dante.de) and switch to the directory tex-archive/systems/msdos/ emtex/lj_fonts. This directory contains several subdirectories with FLI files (EmTeX font libraries). Just get all these files and put them in your base directory; dviwin will use them automatically. When you do this, make sure that you get rid of any dvivga fonts at resolutions of 300dpi or above, to avoid wasting space on duplicate fonts. I am still unclear about the font setup. Can you give an example? My base directory is "c:\usr\texfonts". Under this directory I have subdirectories called "70", "76", "84", "92", "100" and so on. Each of these subdirectories contains a full set of PK fonts for the particular resolution. Therefore, when dviwin looks for cmr10 at 100dpi, it should look for the file "c:\usr\texfonts\100\cmr10.pk"; this is accomplished by telling dviwin that the font directory is "c:\usr\texfonts\$r". The same specification will also work if you want to use "fli" files in the base directory (c:\usr\texfonts). I am using another dvi driver and the names of the subdirectories are c:\tex\pkfonts\100dpi, c:\tex\pkfonts\110dpi, etc. How can I instruct dviwin to use these directories? Specify the font directory as "c:\tex\pkfonts\$rdpi" and everything will be fine. The program cannot find the fonts lcircle10 and lcirclew10. Why does this happen? These names exceed the DOS limit of 8 characters. If you try to create such files under DOS, the names will be truncated to "lcircle1" and "lcirclew" respectively. Dviwin will find these files in the PK format, but you may encounter problems if you store them in a font library without any name remapping. The easiest way around this problem is to add the following lines to the font substitution file: lcircle10 -> lcircle1 lcirclew10 -> lcirclew If you use the dvivga fonts from the simtel archives, you will find that they have renamed these two fonts to "circle10" and "circlew1" respectively. In that case, change the two substitution lines as following: lcircle10 -> circle10 lcirclew10 -> circlew1 The file "dviwin.sub" already contains the last two substitutions. so you don't need to change anything if you use the dvivga fonts. The program cannot find some fonts even though they are installed on my disk. If the font directories are specified correctly, this may indicate that there are not enough file handles in the system. Make sure that you use a value of at least 50 for the FILES statement in your config.sys file. I have some emTeX font libraries in the base directory, but dviwin does not use them. Older versions of emTeX used another format for the font libraries; this format is now obsolete, and dviwin supports only the new format. If you have such libraries, you can update them to the new format by using a recent version of the "fontlib" program which is distributed with emTeX. I have emTeX font libraries for the Epson 9-pin printers; these font libraries use the new format, but dviwin still does not use them. The fonts in these libraries have a horizontal resolution of 240dpi and a vertical resolution of 216dpi. This corresponds to the highest possible resolution using 9-pin printers, but the standard Windows drivers do not support this resolution. You can get good results by generating 240x144 dpi fonts (with Metafont), adding this resolution to dviwin and setting the printing resolution (in the Print dialog) to "Auto". If you create FLI files out of the PK fonts, I would strongly recommend that you add the comment "0.6" (the aspect ratio) to the FLI files; this will prevent any confusion with other FLI files having the same horizontal resolution. I have already generated several font libraries containing all fonts for plain TeX, LaTeX (but no SliTeX) and some utility fonts used by Knuth (logo* and manfnt). These libraries contain the proper comment indicating the aspect ratio to dviwin; you can find them in the directory "tex-archive/systems/msdos/emtex/fx_med_fonts" at the CTAN hosts (ftp.shsu.edu, ftp.tex.ac.uk or ftp.dante.de) under the names "fx_med_*.fli". I have a 24-pin printer; I sometimes want to use the 360x180dpi mode, while other times I want to use the 360x360dpi mode. Is this possible with dviwin? Dviwin can easily handle this case, provided that you have the correct fonts and the font specification is unambiguous. If you use PK files, I would suggest that you add the directories "360x180", "360x360", etc. under your base directory, and you add the suffix ";XXXX\$xx$y" to the directory specification (where XXXX is your base directory). If you prefer to use FLI files, then you can simply put all of them in the font base directory, but make sure that you add the comment "0.5" (the aspect ratio) to all 360x180 libraries, and the comment "1.0" to all 360x360 libraries. If you don't do this, dviwin will not be able to distinguish between the two sets of fonts (because the FLI format does not specify the vertical resolution explicitly), and the output will definitely be messed up. I have fonts for a 300dpi printer as well as for a 24-pin printer. The printing output is often incorrect. What is the problem? This may indicate that dviwin is confused about the vertical resolution of your fonts. When using the 300dpi printer, magstep1 corresponds to 360dpi, which is equal to magstep0 for the high (360x360) or medium (360x180) resolutions of the 24-pin printer. If the 24-pin fonts are for the medium resolution, dviwin may be confusing these fonts to the 360x360 dpi fonts used by the 300dpi printer at magstep1. The best solution for this problem is to follow the instructions in the previous question in order to eliminate any ambiguity in the font selection. I have installed the "share.exe" program and I am getting sharing violations. Why does this happen? The basic idea behind share.exe is to arbitrate file access among different processes. Unfortunately, the implementation is not that great and sometimes it complains even if two or more processes try to read the same file (this is wrong: it should complain only if a program tries to read a file while another is writing it). You can placate it by setting the attributes of the files in question to "Read Only". I have PK fonts at 118dpi and I don't want to waste space by installing new fonts at similar resolutions. Is there a way to use my fonts? The first version of dviwin could use only the resolutions appearing in the "Resolution" submenu. Newer versions let you add two custom resolutions to the submenu, so you can use any fonts that you like. You can select the entry "Custom Resolutions" from the "Options" submenu, and you will see a dialog box where you will specify the resolutions that you want. As soon as you do this, you can select any of these resolutions from the "Resolution" submenu. Why do you use these particular font resolutions? they do not follow the standard geometric progression exactly. What if I want to use the proper progression? I decided to use these fonts in order to remain compatible with other drivers from the Beebe family, and because the appropriate fonts are already at simtel, so anybody can download them. It would be an enormous waste of space and bandwidth if I required everybody to obtain new fonts. These resolutions are not so mysterious as they initially appear: these days, 300dpi printers are probably the most common output devices, so it makes sense to select 300dpi as the "base" resolution. The resolutions 329dpi, 360dpi, 432dpi, etc. are derived by applying standard positive magsteps to the base resolution. CRT devices have considerably fewer pixels and most older dvi drivers could not "zoom" the fonts; one solution was to generate fonts at a lower resolution for a particular device (eg., for Sun screens at 118dpi); a variation on this theme was to select the lower resolutions by applying negative magsteps to the base resolution (300dpi). If you apply the formula DPI = 300 * ( 1.2 ^ magstep), you get the following table: Magstep DPI Magstep DPI -8.0 69.77 -2.5 190.18 -7.5 76.43 -2.0 208.33 -7.0 83.72 -1.5 228.22 -6.5 91.72 -1.0 250.00 -6.0 100.47 -0.5 273.86 -5.5 110.06 0.0 300.00 -5.0 120.56 0.5 328.63 -4.5 132.07 1.0 360.00 -4.0 144.68 1.5 394.36 -3.5 158.48 2.0 432.00 -3.0 173.61 2.5 473.23 If you round the above numbers, you will find that they are identical to those used by dviwin. The biggest advantage of this approach is that all resolutions are on the same "scale", so you do not waste disk space on fonts that are close to each other in terms of resolution. If for example you want to print on a FAX board which has a resolution of 200dpi, you have two options: the first option is to get the required magsteps starting at 200dpi; the second option is to use the resolution 208dpi as your base; then you will normally need fonts at 228dpi (magstephalf), 250dpi (magstep1), 300dpi (magstep2), 360dpi (magstep3), 432dpi (magstep4) and 518dpi (magstep5). As you see, the last four magsteps coincide with the resolutions used for the 300dpi laser printers, so you will save a great deal of space if you already have the laser fonts, because you will only need to get fonts at 208dpi, 228dpi and 250dpi. The only disadvantage of this method is that you may not get the exact resolution (ie., the letters on the FAX will be slightly larger), and the 300dpi fonts may not be suitable for the other device (unless you fiddle with the Metafont parameters). It is up to you to decide which method you prefer. If you decide that you want to use a different series of resolutions, you can specify the desired number as a custom resolution in dviwin; if for example you specify a custom resolution of 100dpi and your document uses a font at magstep1, then dviwin will look for the font at 120dpi (instead of 121dpi), because this is the correct number if the base resolution is exactly 100dpi. I want to save space by generating fonts dynamically. How should I go about it? You first need to get a working version of Metafont from the CTAN hosts; you will find sbmf in the directory tex-archive/systems/msdos/sbtex, or gmf in the directory tex-archive/systems/msdos/gtex, or emmf in the directory tex-archive/systems/msdos/emtex. Get the file modes.mf (you will need version 2.1 or later of that file) from the directory tex-archive/fonts/cm/modes and append the mode definitions described in the file "genpk.bat". Read the documentation of your Metafont program and set the appropriate environment variables. Then issue the command: inimf plain;input modes;dump This will generate the plain base (plain.bas) and it will include the appropriate mode information for many devices. Now copy the file plain.bas to your "base" directory. Then get the source files for the plain fonts from the directory tex-archive/fonts/cm/mf at the CTAN hosts, and for the LaTeX fonts from the directory tex-archive/macros/latex/distribs/latex/fonts and put them in the "mfinputs" directory. The next step is to read and edit the file genpk.bat from the dviwin distribution to specify the destination directory for the PK fonts. You will also need the program gftopk.exe which is usually distributed with the Metafont program. Finally select the entry "Missing fonts" from the "Options" menu of dviwin and instruct it to execute the genpk batch file or collect all font requests to a batch file and execute it in one pass; if you run the 16-bit version of the program under OS/2 or NT, or the 32-bit version of the program under 16-bit Windows, select the last option; the other option (to execute genpk for each missing font) does not work well in those circumstances, and you will end up with multiple copies of Metafont running simultaneously. I followed the above procedure, but Metafont produces huge fonts. What is going on? You probably did not include the correct mode information when you generated the plain base. Just generate it again and make sure that you include the file "modes.mf". You also need to make sure that you use version 2.1 or later of the file "modes.mf". Why do you open the font libraries more than once? The program uses a separate file handle for each font even though they may be in the same font library. This lets it exploit the file buffering better and speeds up the font reading somewhat. The printer output is extremely small. What is the problem? The problem was that the first version of dviwin would send the bitmap to the printer at the current resolution. Therefore, you needed to switch to the appropriate resolution for the printer before issuing the "Print" command; this was done for flexibility purposes. Since however most people are annoyed by it, I decided to use another method: the "Print" dialog contains a combo-box that lets you select the resolution used for the printer. This value defaults to "Auto" which means that the program will use a resolution which is as close as possible to the printer's resolution. This will work even when you change the default printer; it is also independent from the previewing resolution. Therefore, you will not need to do anything under normal circumstances. If however you want to produce magnified or reduced output, you can still do it with minimal fuss. When I try to print on a laser printer, the output is weird: the text comes out at the proper size, but it does not fill the page and there are some extraneous characters. This is almost certainly due to insufficient memory in the laser printer. You will need about 1M of RAM at 300dpi and 4M of RAM at 600dpi. This behavior is typical of HP printers; Apple printers reset and print a test page when the memory limits are exceeded. Keep in mind that two-up printing requires more printer memory; you will usually be able to print normal pages on a laser printer equipped with only 512K; if however you try to print two reduced pages on such a printer, you will probably exceed its memory limits. The best solution is to add some memory to your printer; if this is not practical, you can try to select a lower printing resolution from the Printer Setup dialog; if you do this, make sure that you set the resolution to "Auto" in the Print dialog. The program is too slow when printing. Are there any improvements in this version? The lack of speed was due to two problems: the first one was that the first version of the program was using too much memory and Windows would swap excessively if you had 4M of RAM or less. The memory requirements of newer releases have been drastically reduced and it can handle even 400dpi resolutions without significant swapping on 4M machines (you will need at least 6M of RAM for 600dpi printing). The second problem is that the program sends a bitmap to the printer; this method can be slow on high resolution printers; I made some optimizations, but the bottleneck is the interface of the computer to the printer. I run some tests on a 386/25 machine with 4M of RAM; when pressing the PgDn key at 300dpi, dviwin 2.0 needed 15 seconds to display the next page; newer versions need 2.5 seconds; this difference is due only to the reduced memory requirements and the lack of swapping. When however you compare the printing speed between the two versions, the difference is much smaller, because of the computer-printer bottleneck. Note that PostScript printers are particularly hostile to bitmaps; if you use a LaserJet or compatible printer with a PostScript cartridge, you will get much faster output by using the printer in its native mode. I understand the logic behind the printing method, but I still need to use a PostScript printer. Is there anything I can do to increase the speed? Newer versions of dviwin let you attach another dvi driver when printing; therefore, you will get the best results from your PostScript printer if you ask dviwin to call a dvi driver tailored for PS printers. You can do this easily by setting the "External Printer" entry in the "Options" submenu and checking the option "Enable external print" from the Print dialog. If the former is non-empty and the latter is checked, then dviwin will execute the command that you specify. The dviwin documentation describes the templates for several dvi drivers. You can also see (and edit) the printing command right before it is executed if you check the option "Preview external print" in the Print dialog. There is one thing that you should be keep in mind if you use the "share" program: when dviwin executes an external print command, it closes the dvi file but not the PK or FLI files; therefore, the other dvi driver can read the dvi file, but you will get sharing violations for the font files (because of a deficiency in share). You can rectify the situation easily by setting the attributes of all font files to "Read Only"; if however you try to restore the dviwin window before the external driver has finished, then you will get another sharing violation about the dvi file and dviwin will complain that it cannot access that file. There is no easy solution around this problem; you either have to wait until the external driver has finished, or avoid using share. I am running another dvi driver through the External Print option, but it complains that it cannot find many fonts even though they are installed, and the path specification is correct. The system is probably running out of file handles. You can rectify this easily by specifying a high enough value in the "FILES=..." statement in your config.sys file; I would suggest a value of at least 50, but you may need to increase it further if you run many programs concurrently and each program accesses many files.. Is there a way to print two TeX pages on a single physical page? The easiest way to accomplish this task is to use the program "dvidvi" (or dvi2dvi) in conjunction with the driver. There are two common page orderings: the first one is to print pages [1,2] on the first physical page, [3,4] on the second, [5,6] on the third and so on. This can be used for program listings. The second useful page ordering is to shuffle the pages for making a booklet; if there are N pages in the document (and N is even), you will want pages [N,1] on the first physical page, [2,N-1] on the second, [N-2,3] on the third and so on. Then you can just put staples in the middle, fold the paper and the booklet will be ready. In both situations you will also want to print the odd physical pages in one pass and the even ones in a second pass; in this way, you can re-insert the paper from the first pass to the printer to get double sided printing (keep in mind that some printers are not really good at this, so you may need to do it with a copier). Suppose now that the input file is "xyz.dvi" and you want to use the first ordering (for program listings). You can issue the commands: dvidvi 4:0,1(8.5in,0in) xyz.dvi xyz1.dvi dvidvi 4:2,3(8.5in,0in) xyz.dvi xyz2.dvi These commands will produce the files "xyz1.dvi" and "xyz2.dvi" which contain the reordered pages. If on the other hand you want to use the second ordering (for booklets), you can issue the commands: dvidvi 4:-3,0(8.5in,0in) xyz.dvi xyz1.dvi dvidvi 4:-1,2(8.5in,0in) xyz.dvi xyz2.dvi You will again get the files "xyz1.dvi" and "xyz2.dvi" but the page ordering will be different. For A4 paper, use the dimension "210mm" instead of "8.5in" in all the above commands. Now start dviwin and select a Ledger page size (17in by 11in); for European paper, select the A3 landscape size (420mm by 297mm). There are two ways to proceed from here: if the printer can handle such a large paper size, just print it at the appropriate resolution and reduce the output with a photocopier; this will give you great results because the effective resolution will be higher. If however the printer cannot handle such paper, we can reduce the output with dviwin; from the "Print" dialog, select a resolution between 65% and 75% of the actual printer resolution. In the printer "Setup" dialog, select Landscape printing, and in the Alignment dialog select automatic page positioning. If for example you use a laser printer capable of handling only Letter or A4 paper at 300dpi, you will probably use a resolution of 208dpi (you can go to 228dpi if you use a wide margin format such as LaTeX). This arrangement will let you print the file in the desired manner. Up to this point, we assumed that the original dvi file was intended for normal printing; this has the advantage that you do not need to change anything in the TeX file. If however you are willing to modify the TeX file for this printing method, you can make the text a bit narrower and taller to fit as much of the page as possible; you can also experiment with the parameters of dvidvi. You can find dvidvi in the directory pub/os2/all/unix/tex of ftp-os2.nmsu.edu; dvi2dvi can be found in the directory pub/msdos/tex of oak.oakland.edu. I used dviwin to print on my dot-matrix printer, but the output is ugly. Older versions of dviwin supported only devices with square pixels; many dot-matrix printers have an aspect ratio which is not equal to one, so the printing quality was marginal. Newer versions support devices with any aspect ratio. Just select the "Custom Resolutions" entry from the "Options" submenu, and enter the appropriate horizontal and vertical resolutions. If the printing resolution is set to "Auto", dviwin will select the correct resolution and fonts for your printer. By the way, you can apply the same method even for the screen in the unlikely case that your video mode has non-square pixels. I am trying to print in landscape mode on a printer with non-square pixels, but the output is awful. Suppose that you use a 9-pin printer at 240x144 dpi. When you print in landscape mode, the actual resolution is 144x240 dpi. The first problem is that dviwin does not even know that this resolution exists. This is easily rectified by specifying this resolution in the "Custom resolutions" dialog from the "Options" menu. The second problem is that there are no commonly available fonts at this resolution, so dviwin will try to use other fonts, which will again lead to ugly output. This can be rectified either by generating all fonts at this resolution manually, or by using the automatic font generation capability of dviwin. In both cases, you will need to get the file "modes.mf" from the directory "tex-archive/fonts/cm/modes" at the CTAN hosts, find the normal mode for your printer and write a new mode which will be identical to the first one, but with transposed resolutions (the files genpk.bat and genpk2.cmd contain mode definitions for the most common printers with non-square pixels). Then generate the fonts using that mode. If you want dviwin to generate the fonts automatically, you may need to edit the file genpk.bat (that file handles the case of the 9-pin, 24-pin and most inkjet printers, but it cannot account for all printing devices). I am still a bit unclear about the graphics capabilities. Can you explain them better? The graphics capabilities are not that complicated. We have two ways to import graphics: the first one is without any graphics filters, and the second one with graphics filters. The first case works only with "standard" or "placeable" metafiles. The second case works with whatever graphics files are supported by your filter. Consider the first case (without filters). You make a graph for example with Excel, copy the graph to the clipboard and then run the "clipmeta" program to save the metafile [you can use either the standard (plain) or the placeable format in the "Save As..." dialog]. Let's say that you saved the graph in the file "abc.wmf". Now put the commands \special{anisoscale abc, x-size y-size} \vskip y-size in your TeX file. x-size and y-size are the desired dimensions of the graph (look at the demo.tex file). When you view or print the file, the graphic should be fine. Consider now the second case (with the filters). We will do the same example as above, but suppose that you want to import a TIFF file.The first and most important requirement is that you have the appropriate filter. If for example you have Word for Windows, you will need the file "tiffimp.flt". You will also need an entry in your win.ini file as: [MS Graphic Import Filters] Tagged Image Format(.TIF)=c:\binw\filters\tiffimp.flt,TIF This line instructs dviwin to use the filter "tiffimp.flt" for files with a "TIF" extension. I put it in the directory "c:\binw\filters" but you can put it anywhere you like. Word for Windows adds this entry in "win.ini" upon installation, so you may already have it. Once this step is done, just put the \special{} and \vskip{} commands in your TeX file, and everything should work out fine. The beauty of this setup is that it is extensible: if tomorrow we decide to use a new graphics format, we only need a new filter, and all applications will benefit. If you have Word for Windows, Toolbook, Powerpoint or Pagemaker, the filters are already in your hard disk. Dviwin comes with filters for BMP, PCX, MSP, GIF and XPM files; these filters come with source code; this is meant to help you if you want to write your own filter. I want to import a BMP file using the 32-bit versions of the programs; I have specified the win.ini entries as described above, but dviwin complains that it cannot find the appropriate filter. How can this happen? The 32-bit version of the programs expects to find the filter specification under the section "[NT Graphic Import Filters]" instead of "[MS Graphic Import Filters]". Just add this section to win.ini and make sure that you specify the appropriate path and filenames of the 32-bit filters. If I import a graphics file on top of normal TeX text, the graphic erases everything underneath it, even though its background is white. Is there any way to avoid erasing the surface under the graphic? Each filter has a mode that controls how the graphic is combined with the underlying surface. The default behavior of the filter is to copy the graphic, which implies that everything underneath it will be erased (after all, "white" does not mean transparent). You can control the mode of the filter through the file "filters.ini"; this file consists of one section per filter: each section contains an entry like: mode=XXXX where XXXX can be "copy" (the default), "and", "or", "xor". If for example we want to import the graphic without erasing anything in the underlying surface, we need to set the mode to "and". Therefore, the "filters.ini" file will look like: [bmp] mode=and [msp] mode=and [pcx] mode=and [gif] mode=and [xpm] mode=and Note that the first section ([bmp]) handles the DIB and RLE files as well, since all these files are handled by the same filter (bmpin.flt). I tried to import an HPGL or a PIC file using the filter supplied with Word for Windows 2.0, but nothing is displayed. What is the problem? This is a bug in the graphics filter: it is supposed to set the window limits when importing the graphics file, but it doesn't do it, and Windows draws the entire graphics file on a single pixel. Word for Windows knows about this problem and fixes it silently. I did the same thing in the new release, and these files now display properly. Keep in mind that some of these filters have bugs and limitations too. I tried to import a PostScript file but I can only see an empty rectangle. The problem is that the EPS filter cannot really display a PS file. It can display a TIFF file embedded in the PS file for previewing purposes (which is by the way quite ugly). If no preview file exists, it just creates an empty rectangle to indicate the location of the graphic. If however you print the file on a PS printer, the filter sends the actual PS graphic and the output will be ok. So that particular filter is not useful; is there any way to display PostScript graphics? The most logical way to accomplish this would be to have a filter that interprets a PS file and creates a metafile. This would benefit not only dviwin, but any program that imports graphics. Therefore, we would need the entire functionality of a PS interpreter (eg., Ghostscript) in a filter; unfortunately, PS is much more complicated than a normal graphics format (Ghostscript is still incomplete even after 6 years of development by many people), so I am rather pessimistic about the availability of such a filter (especially at a low price). Why don't you distribute more graphics filters with dviwin? Because I have only so much time available; the GraphIO library comes with full source code and sample code for five filters. That should be enough to get you started if you really need another graphics filter. If you absolutely need to import another kind of graphic file and you don't have access to any appropriate filter, you may try to open the file with a drawing program and save it as a BMP file, so that dviwin can import it. Paint Shop Pro (available at ftp.cica.indiana.edu) can handle most graphics formats. When I insert a metafile in my document, the text inside the graphics file looks ugly. Is there a way around this problem? This usually happens if you use a non-scalable font in the metafile. Try using the "Times New Roman" font instead. Microsoft also sells a larger collection of TrueType fonts; if you have it, you can get pretty good results by using the "Century Schoolbook" font which blends better with the cmr fonts. I am trying to include a color graphics file in my document and I have a color printer, but dviwin converts the graphic to black and white. Why? The program uses a monochrome bitmap for the rasterization of the document; therefore, Windows converts any colors to black and white automatically. The reason for this behavior is that a monochrome bitmap takes much less memory and can be displayed faster than a color bitmap. Still, you can print any graphics files in full color, by checking the option "Send specials to printer" in the Print dialog. This instructs dviwin to send the graphics directly to the printer, so it will exploit any special capabilities of your printer; the disadvantage of this method is that the screen output may be different from the printed output (since the screen output is always monochrome). I want to include some bitmapped graphics in my document; dviwin does import them, but they look very ugly. Is there a way to improve their appearance? There are two basic problems with bitmapped graphics: scaling and color assignment. 1. Bitmapped graphics cannot be scaled easily; if you instruct dviwin to scale such graphics, dviwin passes this request to Windows which does not do a good job in scaling the graphic. The best way to print a bitmap is to print it at its natural size (ie., each pixel in the bitmap should correspond to a pixel in the printing device). This can be achieved by computing the graphic dimensions at the intended printing resolution and supplying these values to dviwin in the \special command; suppose for example that you want to print the file "abc.wmf" which is a 640x480 bitmap on a 300dpi printer; the printed dimensions will be 640/300 = 2.1333in by 480/300=1.6in. You can then give the command: \special{center abc, \the\hsize 2.5in 2.1333in 1.6in} which will print the bitmap without any scaling. This implies of course that the dimensions specified in the \special command are completely device-dependent: if you want to print the same document on a dot-matrix printer with different resolution, you will have to compute the required dimensions again. It is not a particularly appealing method, but you will get the highest possible quality from your output device. A natural consequence of the above statement is that the screen output of dviwin may not look good if the selected resolution is not equal to the printing resolution; it will look just fine if you select the printing resolution in conjunction with a zoom factor. Newer versions of dviwin let you specify the graphic's dimensions in pixels. Using the bitmap from the above example, we can specify the special command as: \special{center abc, \the\hsize 2.5in 640px 480px} and dviwin will take care of all conversions. You only need to leave enough vertical space in your document. Note that we specified the bitmap's dimensions in the \special command; this is absolutely necessary even when using a graphics filter, because clipmeta does not know the resolution of the device on which you want to print the bitmap, so it cannot provide any reasonable dimensions. 2. The second issue applies to monochrome printers only. If you mark the option "Send specials to printer" in the Print dialog, the color conversion is done by the printer driver, so the results depend on its quality. If the option in not checked, dviwin will send the monochrome bitmap to the printer, so the printer driver is not involved in any color conversions. Windows does the color conversion when it imports the graphic, but the results are usually bad because it uses a simple algorithm to assign some colors to black and other colors to white. You can achieve much better results if you use a dedicated painting program to reduce the colors before you produce the metafile. For this operation, I would recommend Paint Shop Pro which is a very nice shareware program and you can find it in the directory pub/pc/win3/desktop at ftp.cica.indiana.edu under the name pspro200.zip; it can reduce the colors using several dithering algorithms and you will get great results on most printing devices. If you follow the above steps, you will usually find that the printed bitmap is too small (at least if the printer has a sufficiently high resolution). The solution to this problem is to scale the bitmap with a painting program before importing it to dviwin; any decent program should be able to handle scaling by an integer factor without any geometric distortions. If you are also doing a color reduction, make sure that the scaling is done before the dithering; in this way, the dithering algorithm has more pixels over which to distribute the error, and you will get excellent results. If on the other hand you do the scaling after the dithering, you will end up with large, ugly pixels. I understand that all these steps sound a bit cumbersome, but it is not trivial to handle bitmaps properly; I think that the proposed method yields better results than most other methods. I am getting GP faults while importing a large graphics file. What is the problem? Many video drivers do not handle large bitmaps well and produce GP faults. These faults are not due to dviwin; they will occur with any program that asks the driver to display the bitmap. Newer versions of clipmeta take care of this problem by splitting large bitmaps into smaller pieces; this is done automatically, so you don't need to worry about it; the only thing that you may want to consider is that some programs export metafiles which simply contain the bitmap (PaintBrush is such an example). Clipmeta will then export the metafile, and it will not be able to split it into pieces, because it does not examine the metafile contents; therefore, you will end up with a big bitmap that may cause GP faults. If on the other hand there is only a bitmap in the clipboard, clipmeta will split it into pieces before creating the metafile. Therefore, if you are trying to export bitmapped data, make sure that you get the actual bitmap into the clipboard instead of a metafile; clipmeta will take care of the rest. If you use PaintBrush, make sure that the entry "Omit Picture Format" in the "Options" submenu is checked. Please read the clipmeta documentation for more info about that program. I am trying to include a graphic in my document, but I only get a solid black rectangle. Some programs cannot export a Device Independent Bitmap (DIB); they only export a Device Dependent Bitmap (DDB) and they do not send an accompanying palette; this will work on a 16-color mode (because the palette is fixed) or on HiColor and TrueColor modes (because there is no palette). On a 256-color mode however, the results are disastrous: the bitmap colors depend on the palette that was current at the time that the bitmap was displayed, but it is most likely that these particular colors will not be available when you use the bitmap in your document. The result is that the colors will be completely wrong and you often end up with a solid black picture. That's one of the reasons for my recommendations against using DDBs. The only way out of this problem currently is to use an application that sends a DIB or an accompanying palette to the clipboard. The program fails to display large arcs or chords generated from tpic specials. This is a genuine Windows bug; if the pen size or the arc radius or the resolution is sufficiently high, then Windows draws the arc with an invisible pen. Win-OS/2 has the same problem. NT displays the arc, but exhibits another bug: the circumference of the arc does not end at the right places. You will not encounter these bugs under normal use. If you do encounter them and you absolutely need to print such large arcs, edit the file dviwin.ini and set the option "winarcs" to zero (ie., there should be a line that reads "winarcs=0"). This instructs dviwin to generate the arcs on its own using a polygonal approximation; the output will be marginally worse than the Windows arcs (a bit rougher), but this is better than no output at all. This option is somewhat hidden because I do not anticipate that anybody will encounter this problem under normal use. How does the refresh capability work? When you switch to another program, dviwin closes the dvi file but keeps the time and date information of that file. When you switch back to dviwin, it checks the time and date information of the dvi file, and if it is different, then it reloads the file but keeps you at the same position as before. It also tries to re-use as many of the old fonts as possible, so the reloading should be much faster than the initial loading. This approach is extremely useful if you wish to integrate the editing and previewing; suppose that you edit a file, run TeX and start the previewer. If you see something wrong, you only need to switch to the editor and rerun TeX; as soon as you switch to the previewer, it will load the new version of the file automatically (and quickly). You can also automate the process even further if you use a good editor and a batch language for Windows. Another advantage of this approach is that it does not depend on DDE or other Windows intricacies, so it will work with any version of TeX. What are the advantages of the font cache? how large should it be? Windows is quite slow in accessing the disk (much slower than DOS); this is a big disadvantage for dviwin which needs to access the dvi file as well as the fonts. Therefore, I decided to keep old fonts just in case we may need them again in another document. When you close a document (either explicitly or by loading another one), the old fonts are not discarded; they are kept in the font cache. If the new document needs any of the fonts in the cache, it will take them from there, so the loading will be much faster. You obviously need to set a limit in the cache size (otherwise you will run out of memory), but this limit depends on the type of your documents as well as the available memory. A cache size of 10 should be a good initial value; then you can observe the number of fonts in the cache from the "Cache Size" entry in the "Options" submenu; a relatively good heuristic is to adjust the cache size so that it is usually almost full. You will need of course to take the amount of available RAM into consideration. The program clears the cache completely when printing; at that point, you probably need all the RAM that you can get. I start dviwin and load a document. The cache size is 10 but I see no fonts in the cache. How is this possible? Only currently unused fonts are in the cache. If you start dviwin and load a file, it will read all the fonts required by that file, but all of the fonts are "in use". Therefore, the cache will be empty. If you load a second file (or a revised version of the same file) which does not use all the fonts from the first file, then you will see some fonts inside the font cache. The display looks fuzzy when I zoom. Why does this happen? is there a way to improve the readability of fonts? When you use high resolution fonts in conjunction with zooming, the program uses a method called "anti-aliasing" to produce the reduced characters. These characters are rather fuzzy because of the color interpolation. You can improve the readability of the text by adjusting a color interpolation parameter from the "Options" submenu. What is the color interpolation parameter? When you use a zoom factor greater than one, dviwin needs to use several colors between the foreground and background colors in a visual sense. The naive approach is to use a linear interpolation between the two colors. To use for example black letters on a white background, one may try to use a 25% gray, a 50% gray and a 75% gray. This works, but it ignores two fundamental nonlinearities: the human eye has a logarithmic response to changes in luminance, and the actual brightness of a pixel (as measured by a photometer) is not necessarily a linear function of the voltage applied to the CRT. One usually deals with these phenomena by applying "gamma correction" which is simply a power function. The color interpolation parameter is a monotonic transformation of the gamma correction parameter generalized for any combination of colors. We use a monotonic transformation simply for convenience in the selection of values. The transformation is set so that a zero value implies a linear function (ie., gamma=1); as the transformation parameter goes to +100, gamma moves towards positive infinity; as the transformation parameter approaches -100, gamma goes to zero. Why is the close-up view so coarse? When the zoom factor is greater than one, the magnifying glass displays the "unzoomed" text which should look just fine. When however the zoom factor is equal to one, the close-up view is obtained by taking the actual bitmap and doubling the bits in both axes; therefore, it is not surprising that it is ugly. The alternative is to open new fonts at higher resolutions and typeset the page again, but this will take enough time to be unusable; other dvi viewers disable the magnifying glass when the zoom factor is equal to one. You mention that there is a limit of 17 open font files. Why? Are there any other limits? The C compiler imposes a limit of 20 open files for buffered I/O; apart from the fonts, dviwin opens three files: the dvi file, the log file and the font substitution file. Therefore, there are 17 files available. We can use a higher limit with unbuffered I/O, but the net speed effect is negative. There are a few other limits too: 1. The maximum number of Windows fonts inside a single metafile is 20. 2. The maximum custom resolution is 3000dpi (this is just a sanity check). 3. The unpacked raster for a single character cannot exceed 64K bytes. 4. The maximum number of pages in the dvi file is 16384. 5. The maximum size of the TeX stack is 2048. 6. The maximum size of the parameters of a \special{} command is 32K bytes. 7. The maximum length of a single path in a tpic special is 16000. 8. The maximum number of points inside a single emTeX special is 10000. The last six limits come from the 16-bit architecture of Windows 3.x (ie., there are no preallocated arrays). I think that all these limits are sufficiently high as not to be binding. The 32-bit version of the program increases these limits by a factor of 1000; it is virtually guaranteed that you will run into other O/S related limits, before reaching the dviwin limits. Is there a way to search for text inside dviwin? There is currently no way to do this: however, newer versions of dviwin support certain specials which facilitate the integration with TeX and an editor; this approach looks more promising than the text search capability. Please read the section "Interaction with TeX and other programs" in the help file for more details about this approach. I have read about the forward and inverse search facility, but I don't know how to generate the src specials. Is there any way to use these facilities right now? The file "demo.tex" contains the following macros: \def\SScurfname{ \jobname.tex} % Note the space before \jobname \def\SSone{\special{src:\the\inputlineno\SScurfname}} \everypar={\SSone} These plain TeX macros insert the appropriate src special at the beginning of each paragraph, so dviwin can do both searches. You can also use the following macros for LaTeX: \def\SScurfname{ \jobname.tex} % Note the space before \jobname \def\SSone{\special{src:\the\inputlineno\SScurfname}} \everypar={\SSone} \let\SSbegin=\begin\renewcommand{\begin}{\SSone\SSbegin} \let\SSend=\end\renewcommand{\end}{\SSone\SSend} \let\SSitem=\item\renewcommand{\item}{\SSone\SSitem} These macros however present the following problems: 1. They work only with Plain TeX or LaTeX; they may require changes for other formats. 2. The \SScurfname macro does not take any included files into account. Therefore, the src specials are erroneous in the presence of included files. 3. Dviwin needs src specials at the beginning and end of each page, at the beginning and end of each column (for multi-column text), and the beginning and end of each included file. The src specials at the beginning and end of each page are especially crucial, but they are also hard to generate with TeX macros (one needs to modify the output routine of plain TeX; I don't know how one can do it under LaTeX). Even with all the above problems, dviwin is able to conduct both searches, but it is not as accurate as possible. It should be obvious that these macros are an interim solution; the next version of BCTeX is expected to generate src specials automatically; this will eliminate the need for any TeX macros and it will work with any format. In the meantime, all contributions about generating src specials through TeX macros are very welcome. Can I use virtual fonts with dviwin? The current release cannot use these fonts. I plan to support them in the future. Is there a way to use TrueType or PostScript fonts in my TeX documents? I have some ideas about using any Windows font (TrueType, ATM or even the bitmapped fonts) without using any PK files and I plan to work on it. The main problem is how to produce a TFM file; I know about afm2tfm and the virtual fonts that come with dvips, but the ATM encoding differs from the Adobe encoding; apart from this, I have not seen any TFM files for TrueType fonts; any help on this topic would be greatly appreciated. Once the TFM files are in place, you will only need a few macros to set up your document. Keep in mind however, that these fonts will not be as common as the cm family, so you will lose some portability. The basic premise of such fonts is that they save you some disk space by eliminating the need for many PK fonts, but you will still need the standard PK fonts if you want to read or print documents written by other people. Is there a way to customize the menus and messages of dviwin? Starting from version 2.9, you can customize all menu entries and messages produced by dviwin. All strings reside in the file dviwin.str which is read upon startup. This facilitates the adaptation of the program to any 8-bit language; please read the section "User defined strings" in the manual for more info about this feature. The standard distribution of dviwin includes several versions of the string file for various languages; if you use another language and you feel left out, you are very welcome to contribute your translation, which can be distributed with the next version of dviwin if you want to. ction with TeX and other progrvrnjhd`\bXTPLk  @ 'wso+k< g c _ [WSOjKk jwsokQgxc_:[WSOKk wsuo!k "g"c#_<$[ &W&S*O*Kk *2w3s8o9k9g9c:_X:[\;W;SW<O<Kk <<w?s?o@k]CgCcC_ D[HWHSHOIKk IJOwPsQQoQk^gh^c`_6a[*fWfSoOoKk oqwqsuovkwgwcy_y[|WR|ST|O]~Kk ]~a~w~sokSgc_[WSݎOKk %w+sokg c_[}WΜS2OYKk YWws okgc_[جWSOűKk űݳw8soµk1gcc_d[FWKSOKk w]sokbgcc_d[FWKSOKk\=<h<h<h\\\\\b\d\\\\+\-\8 \: \< \<h< \ \ \ \ \ \ \ \\\\\\\\<hj\l\\\6\ \&\A\\\\\\\\<h\Q\S\t\v\x\\\6\8\:\\\\\<h\u\w\!\!\!\ "\"\#\#\#\<$\>$\&\ &\<h & &\&\&\*\*\*\*\+\)+\P+\w+\+\+\+\,\<h,5,\[,\,\,\F1\H1\2\2\2\3\3\O5\q5\9\:\<h::\X:\Z:\X;\Z;\\;\;\;\S<\U<\W<\<\<\?\?\<h??\@\@\C\C\C\ D\ D\H\H\H\I\I\FO\HO\<hHOJO\P\P\MQ\OQ\QQ\Q\Q\U\U\V\FV\HV\W\W\<hWCW\sW\uW\[\[\^\^\^\h^\j^\`\`\`\6a\8a\<h8a&f\(f\*f\f\f\g\g\)i\+i\Vi\gi\ii\j\j\rk\<hrktk\k\k\k\l\l\o\o\o\o\o\q\q\q\q\<hqq\s\s=tt<h<h<htt\t\t\t\t\t\t\t\t\u\u\u\v\v\w\<hww\w\x\x\y\y\y\y\y\|\|\|\R|\T|\]~\<h]~_~\a~\~\~\\\\\\O\Q\S\\\C\<hCE\=<~\\<h<h<h<\\\=.<h<h<h.0\M=O?.<h<h<h?A\\\\ \ \\\\\\y\{\}\Μ\<hΜМ\.\0\2\Y\[\S\U\W\\\\\ \\<h\ \\\\\Ԭ\֬\ج\\\\\\ű\<hűDZ\ٳ\۳\ݳ\8\:\\\Ե=!=<h<h !j\\ն\#\i\\=-=/=1=<h<h 1c\e\\\\d\f\\޻===h<h +\-=ݼ=!Z=h<h=hZp\\\\N==h<h=hN\<\\=======<h<h \]\_\\\\\\b\d\<h<h f=/2!898(h\ \ \ \ \\\\\\\\<hx %d3BQP` m y # X<h Arial\S\t\v\x\\\6\8\:\\\\\<h