Convert DVI into PDF properly
Clash 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
 |Â
show 10 more comments
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
2
Others might like to see examples of the issues you have withrowcolors
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 withrowcolors
, 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
 |Â
show 10 more comments
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
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
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 withrowcolors
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 withrowcolors
, 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
 |Â
show 10 more comments
2
Others might like to see examples of the issues you have withrowcolors
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 withrowcolors
, 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
 |Â
show 10 more comments
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
There are two separate issues with tabular rules and colortbl colored backgrounds.
cline
doesn't work. This is explicitly documented in thecolortbl
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 thecline
over-prints the background of the row above, and the bottom half of thecline
is over-printed by the background of the row below.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.
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
add a comment |Â
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.
cline
doesn't work. This is explicitly documented in thecolortbl
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 thecline
over-prints the background of the row above, and the bottom half of thecline
is over-printed by the background of the row below.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.
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
add a comment |Â
up vote
5
down vote
accepted
There are two separate issues with tabular rules and colortbl colored backgrounds.
cline
doesn't work. This is explicitly documented in thecolortbl
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 thecline
over-prints the background of the row above, and the bottom half of thecline
is over-printed by the background of the row below.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.
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
add a comment |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
There are two separate issues with tabular rules and colortbl colored backgrounds.
cline
doesn't work. This is explicitly documented in thecolortbl
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 thecline
over-prints the background of the row above, and the bottom half of thecline
is over-printed by the background of the row below.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.
There are two separate issues with tabular rules and colortbl colored backgrounds.
cline
doesn't work. This is explicitly documented in thecolortbl
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 thecline
over-prints the background of the row above, and the bottom half of thecline
is over-printed by the background of the row below.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.
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
add a comment |Â
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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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