Convert DVI into PDF properly

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












For viewing my work when I'm programming LaTeX, I decided to use the DVI format.
The reason is that the result is perfect compare to the PDF.



For example, the borders of tabulars appear perfeclty even if I use rowcolors or other exotic stuf. It doesnt in PDF. Even if I'm zooming-in, sometimes it doesnt show up.



But my main issue with that is that I need to be able to generate a document to distribute to all my collegues. The PDF format is mainly known and used.
So I would like to generate a PDF from the DVI.



I have this option on TeXnicCenter, but the result is almost the same that with the direct conversion in PDF.
Is there a way to generate a PDF from a DVI that look exactly the same ?



Is there another option of all this ?






pdf colortbl dvi convert







share|improve this question



















  • 2




    Others might like to see examples of the issues you have with rowcolors and viewers. I don't think many go about the regular dvi route anymore.
    – daleif
    3 hours ago






  • 1




    @joseldsm The conversion should respect the document properties. The rendering is done by the viewer (I have a pdf viewer that shows the dvi pixelated, and another which shows basically the same as the pdf). Try another viewer for both pdf and dvi to see if there's a difference. Also, show what problems are you having with rowcolors, so we can check too.
    – Phelype Oleinik
    3 hours ago






  • 1




    What you ask isn't possible because the disappearing rules are a property of the pdf viewer being used, not of the pdf file.
    – David Carlisle
    3 hours ago






  • 3




    In the case of clines, that is user error the colortbl documentation makes it explicit that clines do not work with coloured backgrounds.
    – David Carlisle
    3 hours ago






  • 1




    I just posted an answer but the differences are unrelated to DVI/PDF it's just that the different formats force you to use different viewers, you would see similar difference using two different dvi viewers or two different pdf viewers
    – David Carlisle
    3 hours ago















up vote
1
down vote

favorite












For viewing my work when I'm programming LaTeX, I decided to use the DVI format.
The reason is that the result is perfect compare to the PDF.



For example, the borders of tabulars appear perfeclty even if I use rowcolors or other exotic stuf. It doesnt in PDF. Even if I'm zooming-in, sometimes it doesnt show up.



But my main issue with that is that I need to be able to generate a document to distribute to all my collegues. The PDF format is mainly known and used.
So I would like to generate a PDF from the DVI.



I have this option on TeXnicCenter, but the result is almost the same that with the direct conversion in PDF.
Is there a way to generate a PDF from a DVI that look exactly the same ?



Is there another option of all this ?






pdf colortbl dvi convert







share|improve this question



















  • 2




    Others might like to see examples of the issues you have with rowcolors and viewers. I don't think many go about the regular dvi route anymore.
    – daleif
    3 hours ago






  • 1




    @joseldsm The conversion should respect the document properties. The rendering is done by the viewer (I have a pdf viewer that shows the dvi pixelated, and another which shows basically the same as the pdf). Try another viewer for both pdf and dvi to see if there's a difference. Also, show what problems are you having with rowcolors, so we can check too.
    – Phelype Oleinik
    3 hours ago






  • 1




    What you ask isn't possible because the disappearing rules are a property of the pdf viewer being used, not of the pdf file.
    – David Carlisle
    3 hours ago






  • 3




    In the case of clines, that is user error the colortbl documentation makes it explicit that clines do not work with coloured backgrounds.
    – David Carlisle
    3 hours ago






  • 1




    I just posted an answer but the differences are unrelated to DVI/PDF it's just that the different formats force you to use different viewers, you would see similar difference using two different dvi viewers or two different pdf viewers
    – David Carlisle
    3 hours ago













up vote
1
down vote

favorite









up vote
1
down vote

favorite











For viewing my work when I'm programming LaTeX, I decided to use the DVI format.
The reason is that the result is perfect compare to the PDF.



For example, the borders of tabulars appear perfeclty even if I use rowcolors or other exotic stuf. It doesnt in PDF. Even if I'm zooming-in, sometimes it doesnt show up.



But my main issue with that is that I need to be able to generate a document to distribute to all my collegues. The PDF format is mainly known and used.
So I would like to generate a PDF from the DVI.



I have this option on TeXnicCenter, but the result is almost the same that with the direct conversion in PDF.
Is there a way to generate a PDF from a DVI that look exactly the same ?



Is there another option of all this ?






pdf colortbl dvi convert







share|improve this question















For viewing my work when I'm programming LaTeX, I decided to use the DVI format.
The reason is that the result is perfect compare to the PDF.



For example, the borders of tabulars appear perfeclty even if I use rowcolors or other exotic stuf. It doesnt in PDF. Even if I'm zooming-in, sometimes it doesnt show up.



But my main issue with that is that I need to be able to generate a document to distribute to all my collegues. The PDF format is mainly known and used.
So I would like to generate a PDF from the DVI.



I have this option on TeXnicCenter, but the result is almost the same that with the direct conversion in PDF.
Is there a way to generate a PDF from a DVI that look exactly the same ?



Is there another option of all this ?






pdf colortbl dvi convert




pdf colortbl dvi convert






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 3 hours ago









David Carlisle

471k3810991827




471k3810991827










asked 3 hours ago









joseldsm

395




395







  • 2




    Others might like to see examples of the issues you have with rowcolors and viewers. I don't think many go about the regular dvi route anymore.
    – daleif
    3 hours ago






  • 1




    @joseldsm The conversion should respect the document properties. The rendering is done by the viewer (I have a pdf viewer that shows the dvi pixelated, and another which shows basically the same as the pdf). Try another viewer for both pdf and dvi to see if there's a difference. Also, show what problems are you having with rowcolors, so we can check too.
    – Phelype Oleinik
    3 hours ago






  • 1




    What you ask isn't possible because the disappearing rules are a property of the pdf viewer being used, not of the pdf file.
    – David Carlisle
    3 hours ago






  • 3




    In the case of clines, that is user error the colortbl documentation makes it explicit that clines do not work with coloured backgrounds.
    – David Carlisle
    3 hours ago






  • 1




    I just posted an answer but the differences are unrelated to DVI/PDF it's just that the different formats force you to use different viewers, you would see similar difference using two different dvi viewers or two different pdf viewers
    – David Carlisle
    3 hours ago













  • 2




    Others might like to see examples of the issues you have with rowcolors and viewers. I don't think many go about the regular dvi route anymore.
    – daleif
    3 hours ago






  • 1




    @joseldsm The conversion should respect the document properties. The rendering is done by the viewer (I have a pdf viewer that shows the dvi pixelated, and another which shows basically the same as the pdf). Try another viewer for both pdf and dvi to see if there's a difference. Also, show what problems are you having with rowcolors, so we can check too.
    – Phelype Oleinik
    3 hours ago






  • 1




    What you ask isn't possible because the disappearing rules are a property of the pdf viewer being used, not of the pdf file.
    – David Carlisle
    3 hours ago






  • 3




    In the case of clines, that is user error the colortbl documentation makes it explicit that clines do not work with coloured backgrounds.
    – David Carlisle
    3 hours ago






  • 1




    I just posted an answer but the differences are unrelated to DVI/PDF it's just that the different formats force you to use different viewers, you would see similar difference using two different dvi viewers or two different pdf viewers
    – David Carlisle
    3 hours ago








2




2




Others might like to see examples of the issues you have with rowcolors and viewers. I don't think many go about the regular dvi route anymore.
– daleif
3 hours ago




Others might like to see examples of the issues you have with rowcolors and viewers. I don't think many go about the regular dvi route anymore.
– daleif
3 hours ago




1




1




@joseldsm The conversion should respect the document properties. The rendering is done by the viewer (I have a pdf viewer that shows the dvi pixelated, and another which shows basically the same as the pdf). Try another viewer for both pdf and dvi to see if there's a difference. Also, show what problems are you having with rowcolors, so we can check too.
– Phelype Oleinik
3 hours ago




@joseldsm The conversion should respect the document properties. The rendering is done by the viewer (I have a pdf viewer that shows the dvi pixelated, and another which shows basically the same as the pdf). Try another viewer for both pdf and dvi to see if there's a difference. Also, show what problems are you having with rowcolors, so we can check too.
– Phelype Oleinik
3 hours ago




1




1




What you ask isn't possible because the disappearing rules are a property of the pdf viewer being used, not of the pdf file.
– David Carlisle
3 hours ago




What you ask isn't possible because the disappearing rules are a property of the pdf viewer being used, not of the pdf file.
– David Carlisle
3 hours ago




3




3




In the case of clines, that is user error the colortbl documentation makes it explicit that clines do not work with coloured backgrounds.
– David Carlisle
3 hours ago




In the case of clines, that is user error the colortbl documentation makes it explicit that clines do not work with coloured backgrounds.
– David Carlisle
3 hours ago




1




1




I just posted an answer but the differences are unrelated to DVI/PDF it's just that the different formats force you to use different viewers, you would see similar difference using two different dvi viewers or two different pdf viewers
– David Carlisle
3 hours ago





I just posted an answer but the differences are unrelated to DVI/PDF it's just that the different formats force you to use different viewers, you would see similar difference using two different dvi viewers or two different pdf viewers
– David Carlisle
3 hours ago











1 Answer
1






active

oldest

votes

















up vote
5
down vote



accepted










There are two separate issues with tabular rules and colortbl colored backgrounds.



  1. cline doesn't work. This is explicitly documented in the colortbl manual. cline is implemented such that it takes no vertical space, the rule is a negative space of half the width followed by a rule followed by another negative space of half the width. So if there are coloured backgrounds, The top half of the cline over-prints the background of the row above, and the bottom half of the cline is over-printed by the background of the row below.


  2. Vertical rules and horiziontal rules may vanish at some zoom levels. In the DVI or PDF the coloured panels and rules are specified to very high accuracy as adjacent rules, however a viewing application always needs to snap such coordinates on to the physical pixel layout of the device, so it can happen that the coloured panels either side of a rule due to rounding end up on adjacent or nearly adjacent pixels and so making the rule impossibly thin to see. Some viewers are better at avoiding this than others, it is a property of the viewer, not of the format.


A better way to solve this is not to draw the rules between the coloured panels but to render the table in two or three layers with the coloured panels first, then the data and the rules. That requires two passes over the table though and just isn't the way colortbl works. There are answers on site showing tikz-decorated tables that work this way and so are more robust with respect to pixel rounding in viewers.






share|improve this answer
















  • 2




    using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
    – David Carlisle
    3 hours ago










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "85"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f454618%2fconvert-dvi-into-pdf-properly%23new-answer', 'question_page');

);

Post as a guest

















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote



accepted










There are two separate issues with tabular rules and colortbl colored backgrounds.



  1. cline doesn't work. This is explicitly documented in the colortbl manual. cline is implemented such that it takes no vertical space, the rule is a negative space of half the width followed by a rule followed by another negative space of half the width. So if there are coloured backgrounds, The top half of the cline over-prints the background of the row above, and the bottom half of the cline is over-printed by the background of the row below.


  2. Vertical rules and horiziontal rules may vanish at some zoom levels. In the DVI or PDF the coloured panels and rules are specified to very high accuracy as adjacent rules, however a viewing application always needs to snap such coordinates on to the physical pixel layout of the device, so it can happen that the coloured panels either side of a rule due to rounding end up on adjacent or nearly adjacent pixels and so making the rule impossibly thin to see. Some viewers are better at avoiding this than others, it is a property of the viewer, not of the format.


A better way to solve this is not to draw the rules between the coloured panels but to render the table in two or three layers with the coloured panels first, then the data and the rules. That requires two passes over the table though and just isn't the way colortbl works. There are answers on site showing tikz-decorated tables that work this way and so are more robust with respect to pixel rounding in viewers.






share|improve this answer
















  • 2




    using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
    – David Carlisle
    3 hours ago














up vote
5
down vote



accepted










There are two separate issues with tabular rules and colortbl colored backgrounds.



  1. cline doesn't work. This is explicitly documented in the colortbl manual. cline is implemented such that it takes no vertical space, the rule is a negative space of half the width followed by a rule followed by another negative space of half the width. So if there are coloured backgrounds, The top half of the cline over-prints the background of the row above, and the bottom half of the cline is over-printed by the background of the row below.


  2. Vertical rules and horiziontal rules may vanish at some zoom levels. In the DVI or PDF the coloured panels and rules are specified to very high accuracy as adjacent rules, however a viewing application always needs to snap such coordinates on to the physical pixel layout of the device, so it can happen that the coloured panels either side of a rule due to rounding end up on adjacent or nearly adjacent pixels and so making the rule impossibly thin to see. Some viewers are better at avoiding this than others, it is a property of the viewer, not of the format.


A better way to solve this is not to draw the rules between the coloured panels but to render the table in two or three layers with the coloured panels first, then the data and the rules. That requires two passes over the table though and just isn't the way colortbl works. There are answers on site showing tikz-decorated tables that work this way and so are more robust with respect to pixel rounding in viewers.






share|improve this answer
















  • 2




    using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
    – David Carlisle
    3 hours ago












up vote
5
down vote



accepted







up vote
5
down vote



accepted






There are two separate issues with tabular rules and colortbl colored backgrounds.



  1. cline doesn't work. This is explicitly documented in the colortbl manual. cline is implemented such that it takes no vertical space, the rule is a negative space of half the width followed by a rule followed by another negative space of half the width. So if there are coloured backgrounds, The top half of the cline over-prints the background of the row above, and the bottom half of the cline is over-printed by the background of the row below.


  2. Vertical rules and horiziontal rules may vanish at some zoom levels. In the DVI or PDF the coloured panels and rules are specified to very high accuracy as adjacent rules, however a viewing application always needs to snap such coordinates on to the physical pixel layout of the device, so it can happen that the coloured panels either side of a rule due to rounding end up on adjacent or nearly adjacent pixels and so making the rule impossibly thin to see. Some viewers are better at avoiding this than others, it is a property of the viewer, not of the format.


A better way to solve this is not to draw the rules between the coloured panels but to render the table in two or three layers with the coloured panels first, then the data and the rules. That requires two passes over the table though and just isn't the way colortbl works. There are answers on site showing tikz-decorated tables that work this way and so are more robust with respect to pixel rounding in viewers.






share|improve this answer












There are two separate issues with tabular rules and colortbl colored backgrounds.



  1. cline doesn't work. This is explicitly documented in the colortbl manual. cline is implemented such that it takes no vertical space, the rule is a negative space of half the width followed by a rule followed by another negative space of half the width. So if there are coloured backgrounds, The top half of the cline over-prints the background of the row above, and the bottom half of the cline is over-printed by the background of the row below.


  2. Vertical rules and horiziontal rules may vanish at some zoom levels. In the DVI or PDF the coloured panels and rules are specified to very high accuracy as adjacent rules, however a viewing application always needs to snap such coordinates on to the physical pixel layout of the device, so it can happen that the coloured panels either side of a rule due to rounding end up on adjacent or nearly adjacent pixels and so making the rule impossibly thin to see. Some viewers are better at avoiding this than others, it is a property of the viewer, not of the format.


A better way to solve this is not to draw the rules between the coloured panels but to render the table in two or three layers with the coloured panels first, then the data and the rules. That requires two passes over the table though and just isn't the way colortbl works. There are answers on site showing tikz-decorated tables that work this way and so are more robust with respect to pixel rounding in viewers.







share|improve this answer












share|improve this answer



share|improve this answer










answered 3 hours ago









David Carlisle

471k3810991827




471k3810991827







  • 2




    using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
    – David Carlisle
    3 hours ago












  • 2




    using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
    – David Carlisle
    3 hours ago







2




2




using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
– David Carlisle
3 hours ago




using rules and coloured backgrounds usually makes an ugly table anyway so another less technical way of avoiding the problem is: don't use rules with coloured tables.
– David Carlisle
3 hours ago

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f454618%2fconvert-dvi-into-pdf-properly%23new-answer', 'question_page');

);

Post as a guest
































































Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being “babysat” by supervisor

Image
Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote 31 down vote favorite 4 I hold a PhD in mechanical engineering with a 7 year background in self-guided, self-paced research including 2 years as a graduate level course instructor and a subject matter expert for various engineering projects in a university setting in the United States. For the last 10-11 months, I am working in a research industry in France where my task is to debug C++ spaghetti code written over a period of several years by my current supervisor. It is a team of 2: just I and my supervisor. Diurnally, I am posed with a "bug of the day" to get out of this C++ code. My supervisor generally gives me about 15-30 minutes to solve it and then accosts me about whether or not the task is completed and then rinses and repeats this until the end of the day. Off-late, my supervisor has been holding 6-7 hour long "meetin
Read more

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Image
Clash Royale CLAN TAG #URR8PPP up vote 2 down vote favorite Many fantasy worlds have multiple humanoid species (elves, orcs, humans, etc) living in the same world, in addition to that, they often have the ability to interbreed. And I can't help but question their believability... fantasy-races reproduction interspecies-relations share | improve this question edited Aug 9 at 14:46 Michael Kjörling ♦ 21.1k 10 85 161 asked Aug 9 at 13:13 Chlodio 118 6 closed as unclear what you're asking by MichaelK, Gryphon, John, Vincent, Frostfyre Aug 9 at 15:25 Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question. 3 Stack Exchange exist to
Read more

Confectionery

Image
Prepared foods made with a lot of sugar or other cabohydrates "Sweetmeat" redirects here. For the racehorse, see Sweetmeat (horse). Not to be confused with Sweetbread. This Kransekake is a traditional Scandinavian baker's confection. Confectionery is the art of making confections , which are food items that are rich in sugar and carbohydrates. Exact definitions are difficult. [1] In general, though, confectionery is divided into two broad and somewhat overlapping categories, bakers' confections and sugar confections. [2] Bakers' confectionery, also called flour confections , includes principally sweet pastries, cakes, and similar baked goods. Sugar confectionery includes candies ( sweets in British English), candied nuts, chocolates, chewing gum, bubble gum, pastillage, and other confections that are made primarily of sugar. In some cases, chocolate confections (confections made of chocolate) are treated as a separate category, as are sugar-free versions of
Read more