Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generating PDF in Windows 10 vs Linux #11

Closed
jjvandien opened this issue Jul 3, 2021 · 8 comments · Fixed by #15
Closed

Generating PDF in Windows 10 vs Linux #11

jjvandien opened this issue Jul 3, 2021 · 8 comments · Fixed by #15

Comments

@jjvandien
Copy link

jjvandien commented Jul 3, 2021

This is a strange situation, but I am creating a cross-platform program which includes generating PDFs and I've noticed that PDFs generated in Windows contain a small horizontal line in the middle of the generated PDF, while in Linux there isn't. Furthermore, if I open the Windows-generated PDF in Linux the line is gone.

This only happens if I use CellFormat(), but not if I use Cell(). Help?

EDIT: I just noticed that if I open the PDFs generated in Linux on the Windows machine, there is a line. The line is not present if the PDF is opened in Linux.

Thank you for your time.

@sbinet
Copy link
Contributor

sbinet commented Jul 5, 2021

thanks for using go-pdf/fpdf.

could you post a small program reproducing this issue?

(this may be a bug in one of the PDF readers.)

@jjvandien
Copy link
Author

jjvandien commented Jul 6, 2021

So, I found a fix. On Linux this isn't an issue, but when reading the PDF on Windows 10 I had to "SetFillColor(255,255,255)" to get rid of the horizontal line.

Here is an example of the code that causes the horizontal lone:

func main() {
	pdf := gofpdf.NewCustom(&gofpdf.InitType{
		UnitStr: "in",
		Size: gofpdf.SizeType{2.4, 1.4},
	})
	pdf.SetFont("Arial", "B", 28)
	pdf.AddPage()
	pdf.SetMargins(0, 0, 1)
	pdf.SetAutoPageBreak(true, 0)
	pdf.SetXY(1,0.7)
	//pdf.SetFillColor(255, 255, 255)
	pdf.CellFormat(0,0,"Test", "", 0, "CM", true, 0, "")
	err := pdf.OutputFileAndClose("test.pdf")
	if err != nil {
		fmt.Println("error: ", err.Error())
	}
}

Again, if I don't use "CellFormat()" the line doesn't appear. However, in order to use "CellFormat()" I need to use "FillColor()". It could just be my experience, but I've tried this on 2 physical Windows 10 machines and 1 Windows 10 VM.

@sbinet
Copy link
Contributor

sbinet commented Jul 7, 2021

thanks for the reproducer.

this may hint (even more?) at a PDF reader issue and how they interpret the PDF document.
(on my Linux machine, I don't see anyline with the test.pdf file produced by the following program, when displaying it with mupdf-1.18)
https://play.golang.org/p/lannzfLijt5

which PDF reader were you using on Windows?

@jjvandien
Copy link
Author

On my Linux machines (RHEL and Fedora) there is no line in the PDF, but on Windows there is a line. The PDF readers I tried in Windows 10 were Adobe Acrobat and the reader built into the Edge browser. I do find it odd that if I use the Cell() function the line doesn't appear when viewing files on Windows 10. Let me see if I can provide you with a screenshot of the error in Windows. Give me a moment.

@jjvandien
Copy link
Author

jjvandien commented Jul 7, 2021

This is the PDF in MS Edge in a Win10 VM; this is the same result on a physical Win10 machine:
SS_PDF_EDGE
This is the same PDF in Acrobat in a Win10 VM; this is the same result on a physical Win10 machine:
SS_PDF_ACROBAT

What I find interesting is how in Edge the line is dark and pronounced, yet in Acrobat it is barely noticeable--yet still obvious.

Again, SetFillColor() to white eliminates this issue, but it is still strange that it only affects CellFormat() and not Cell().

@flibustenet
Copy link
Contributor

The issue is not related to Windows, I can reproduce it on Linux with xpdf, chrome and firefox.
It's because fill arg is true with 0 height. With 10 height for example we can see it better. The width is little also because of the size of the page, with standard page size the line is going all the with of the page.

@flibustenet
Copy link
Contributor

I believe this issue can be closed. It's just that fill arg should not be set to true with a 0 height.

@sbinet
Copy link
Contributor

sbinet commented Sep 3, 2021

what about #15 ?

@sbinet sbinet closed this as completed in ebd255b Sep 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants