poppler issueshttps://gitlab.freedesktop.org/poppler/poppler/-/issues2023-03-07T22:24:02Zhttps://gitlab.freedesktop.org/poppler/poppler/-/issues/1370Poppler PDF Info : Long Path Issue (OS: Window 2019 Standard)2023-03-07T22:24:02ZSujith ChandPoppler PDF Info : Long Path Issue (OS: Window 2019 Standard)Hi Team,
We have been using Poppler v21.03.0 since 2020, and recently we have migrated our application to Windows 2019. Currently we are having an issues in accessing PDF files that have 260+ characters in the file path - specific to Wi...Hi Team,
We have been using Poppler v21.03.0 since 2020, and recently we have migrated our application to Windows 2019. Currently we are having an issues in accessing PDF files that have 260+ characters in the file path - specific to Windows 2019 environment.
![image](/uploads/6c92431ba3e81a154de03ab0f3e2d1a1/image.png)
Based on MS article, in order to enable the long path behavior, both of the following conditions must be met in OS 2019 Standard:
- LongPathsEnabled is set to True ( This was already enabled as part of Server build activity )
- Application manifest must also include the longPathAware element --> PDFInfo.exe specific (Nothing to do with Server Configuration)
So we have installed Poppler v23.01.0 as well, but the result is the same. So just wanted to confirm we have the following details in the application manifest file or do we have any workaround / plan to address this issue?
Could you please give me some advice?
Ref Link : https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
![image](/uploads/9f0a5de3a5ab81322de8c4fb78ddb3e4/image.png)
Note : We have a workaround - To specify such a long network path, use the "\\?\UNC\" as prefix. For example, "\\?\UNC\ServerName\Landing\..." . When using \\?\UNC\ in the file path, I was able to read the PDF using PDFinfo.exe. But need to confirm if we have something in backlog to address this issue or if there is any permanent solution for Windows 2019.https://gitlab.freedesktop.org/poppler/poppler/-/issues/1209DllMain quirks with ENABLE_RELOCATABLE2022-02-07T13:39:29ZKai PastorDllMain quirks with ENABLE_RELOCATABLEThe `ENABLE_RELOCATABLE` feature is implemented via a `DllMain` function in lib poppler. This implies that this feature is restricted not only to WIN32 but also to using shared libs.
However, lib `poppler` which carries this `DllMain` d...The `ENABLE_RELOCATABLE` feature is implemented via a `DllMain` function in lib poppler. This implies that this feature is restricted not only to WIN32 but also to using shared libs.
However, lib `poppler` which carries this `DllMain` definition is not build as a shared lib with MSVC: https://gitlab.freedesktop.org/poppler/poppler/-/blob/master/CMakeLists.txt#L587-592. In this way, poppler causes a symbol clash when trying to build another DLL which uses `DllMain`, for example GDAL:
~~~
poppler.lib(GlobalParams.cc.obj) : warning LNK4006: DllMain already defined in gdaldllmain.obj; second definition ignored
~~~
(Mentioned here: https://github.com/OSGeo/gdal/issues/4701#issuecomment-950944044. Now appeared in updating poppler in vcpkg.)https://gitlab.freedesktop.org/poppler/poppler/-/issues/1165Static lib problem2021-10-26T19:56:49ZLukasz KowolStatic lib problemI build new poppler with msvc. When i try to link it to my project I have this problems. Could I build poppler with MT flag?
![image](/uploads/3f565478a34160177159a6bee8a78f4e/image.png)I build new poppler with msvc. When i try to link it to my project I have this problems. Could I build poppler with MT flag?
![image](/uploads/3f565478a34160177159a6bee8a78f4e/image.png)https://gitlab.freedesktop.org/poppler/poppler/-/issues/998poppler-cpp memory leaking on Windows for some pdf2020-12-03T05:45:03Za bpoppler-cpp memory leaking on Windows for some pdf## Env
OS: Windows 10
IDE: Visual Studio 2019
poppler: 20.11.0 x64 msvc
## Problem
Memory leak for some pdf when calling `poppler::page_renderer::render`
## Reproduce
1. Download the pdf<br>
http://www.cninfo.com.cn/new/disclosure/det...## Env
OS: Windows 10
IDE: Visual Studio 2019
poppler: 20.11.0 x64 msvc
## Problem
Memory leak for some pdf when calling `poppler::page_renderer::render`
## Reproduce
1. Download the pdf<br>
http://www.cninfo.com.cn/new/disclosure/detail?plate=szse&orgId=gssz0000672&stockCode=000672&announcementId=1207498718&announcementTime=2020-04-15<br>
Click the blue button on the top right
2. In a Visual Studio solution, include `test.h` and call the function
test.h
```
#pragma once
#include <iostream>
#include <poppler-document.h>
#include "poppler-page.h"
#include "poppler-page-renderer.h"
std::string pdf_file_path(u8"上峰水泥:2019年年度报告.PDF")
void test_poppler_memory_leak()
{
if (!poppler::page_renderer::can_render())
{
std::cerr << "can not render" << std::endl;
return;
}
poppler::document * p_doc = poppler::document::load_from_file(pdf_file_path);
int page_index = 85;
poppler::page * p_page = p_doc->create_page(page_index);
poppler::page_renderer page_render;
poppler::image poppler_img = page_render.render_page(p_page, 120, 120); // it leaks
delete p_page;
delete p_doc;
}
```
3. Leak message sample in Visual Studio 2019
```
{35684} normal block at 0x000001EA57F0CA40, 32 bytes long.
Data: <C:\Windows\Fonts> 43 3A 5C 57 69 6E 64 6F 77 73 5C 46 6F 6E 74 73
{35683} normal block at 0x000001EA57EDDC80, 16 bytes long.
Data: <p4 W > 70 34 EB 57 EA 01 00 00 00 00 00 00 00 00 00 00
{35682} normal block at 0x000001EA57EB3470, 40 bytes long.
Data: < W @ W > 80 DC ED 57 EA 01 00 00 40 CA F0 57 EA 01 00 00
{35681} normal block at 0x000001EA57F0C560, 32 bytes long.
Data: <Courier-BoldObli> 43 6F 75 72 69 65 72 2D 42 6F 6C 64 4F 62 6C 69
{35680} normal block at 0x000001EA57EDDD20, 16 bytes long.
Data: < 5 W > C0 35 EB 57 EA 01 00 00 00 00 00 00 00 00 00 00
```
## More Info
With many other pdf files, it doesn't leak, even include Chinese fonts.
It seems that some fonts lead to memory leaks.https://gitlab.freedesktop.org/poppler/poppler/-/issues/985Unable to convert PDF to TIFF using pdftocairo2020-11-09T21:06:19Zyogi2806Unable to convert PDF to TIFF using pdftocairoTried to use this command in **windows **system using version **poppler-20.11.0** loading:
pdftocairo.exe test.pdf -tiff which generates same output like test.tif file with 0kb.
I was using pdf2Image lib even this lib does the same thi...Tried to use this command in **windows **system using version **poppler-20.11.0** loading:
pdftocairo.exe test.pdf -tiff which generates same output like test.tif file with 0kb.
I was using pdf2Image lib even this lib does the same thing and they wanted to contact you on this issue. Kindly help me out to fix the issue.https://gitlab.freedesktop.org/poppler/poppler/-/issues/907I find a pdf file which can not be rendered correctly.2024-03-09T22:04:16ZChen WeiI find a pdf file which can not be rendered correctly.I'm using a program based on poppler whose name is Xournal++. I found a pdf file which can not be correctly rendered. This file can be downloaded [here](https://github.com/changgyhub/leetcode_101/blob/master/LeetCode%20101%20-%20A%20Leet...I'm using a program based on poppler whose name is Xournal++. I found a pdf file which can not be correctly rendered. This file can be downloaded [here](https://github.com/changgyhub/leetcode_101/blob/master/LeetCode%20101%20-%20A%20LeetCode%20Grinding%20Guide%20(C%2B%2B%20Version).pdf). All Chinese characters in this file are not visible. A screenshot is shown below.
![](https://user-images.githubusercontent.com/24856363/79739407-b9608200-8330-11ea-97db-7e65e18da9d4.png)
For more detail, please check the [issue](https://github.com/xournalpp/xournalpp/issues/1878) I filed minutes ago in github.https://gitlab.freedesktop.org/poppler/poppler/-/issues/848Glyph not displayed using Arthur backend in Windows2019-12-06T14:56:09ZJörg HoffmannGlyph not displayed using Arthur backend in WindowsI've build a poppler-qt5.dll for windows and used it in frescobaldi. Using the splash backend, everything is fine, but when switching over to Arthur, the glyphs are missing.
The PDF: [Untitled.pdf](/uploads/ddf4df599904a35a5036a85b05656...I've build a poppler-qt5.dll for windows and used it in frescobaldi. Using the splash backend, everything is fine, but when switching over to Arthur, the glyphs are missing.
The PDF: [Untitled.pdf](/uploads/ddf4df599904a35a5036a85b0565650c/Untitled.pdf)
Result with splash:
![Splash_](/uploads/943466bc3c8b170c40501fcdf5fc4d89/Splash_.png)
Result with Arthur:
![Arthur_](/uploads/b80cbdbf22462b87f83822a6f7495b8e/Arthur_.png)
When swithing over to Arthur these messages are issued:
```
QWindowsFontDatabase::fontEngine: Can't change family name of font
RawFont is not valid
QWindowsFontDatabase::fontEngine: Can't change family name of font
RawFont is not valid
RawFont is not valid
QWindowsFontDatabase::fontEngine: Can't change family name of font
RawFont is not valid
RawFont is not valid
RawFont is not valid
RawFont is not valid
RawFont is not valid
QWindowsFontDatabase::fontEngine: Can't change family name of font
RawFont is not valid
QWindowsFontDatabase::fontEngine: Can't change family name of font
RawFont is not valid
RawFont is not valid
RawFont is not valid
RawFont is not valid
RawFont is not valid
RawFont is not valid
RawFont is not valid
```
Did I maybe miss something when building poppler?https://gitlab.freedesktop.org/poppler/poppler/-/issues/820bug(pdftoppm): -: Error writing TIFF header.2020-09-23T13:58:33ZСаша Черныхbug(pdftoppm): -: Error writing TIFF header.### 1. Note
If I need post this issue to another place, please, show me this place.
### 2. Summary
I can't convert any PDF document to tif (tiff). In any case I get an error:
```text
-: Error writing TIFF header.
```
### 3. Possible...### 1. Note
If I need post this issue to another place, please, show me this place.
### 2. Summary
I can't convert any PDF document to tif (tiff). In any case I get an error:
```text
-: Error writing TIFF header.
```
### 3. Possible related issues
+ [**Bug 75969**](https://bugs.freedesktop.org/show_bug.cgi?id=75969)
+ Harsh Rai user [**reported**](http://disq.us/p/21m5qus) about this problem
### 4. Data
+ [**KiraGoddess.pdf**](https://app.box.com/s/dyunssgvwrybl5te7vq65nus4qfoeou9) — simple PDF file, that contains solely text `Kira Goddess!`.
### 5. Steps to reproduce
I download and unpack `poppler-0.68.0_x86` from [**here**](https://blog.alivate.com.au/poppler-windows/) as [**described on Stack Overflow**](https://stackoverflow.com/q/18381713/5951529) → I add `poppler-0.68.0_x86\poppler-0.68.0\bin` folder to user `PATH` environment variable → I run this command
```text
pdftoppm -tiff KiraGoddess.pdf KiraGoddess
```
### 6. Actual behavior
```text
-: Error writing TIFF header.
```
### 7. Expected behavior
Converting to JPEG successful for me.
```text
pdftoppm -jpeg KiraGoddess.pdf KiraGoddess
```
+ `KiraGoddess-1.jpg`:
![JPEG](https://i.imgur.com/uAlRJ24.jpg)
### 8. Environment
+ Windows 10 Enterprise LTSB 64-bit EN
Thanks.https://gitlab.freedesktop.org/poppler/poppler/-/issues/678Compiler warnings on Windows (GCC-8)2019-01-12T20:55:18ZJeroen OomsCompiler warnings on Windows (GCC-8)```
[ 20%] Building CXX object CMakeFiles/poppler.dir/poppler/Gfx.cc.obj
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/Function.cc: In member function 'virtual void SampledFunction::transform(cons...```
[ 20%] Building CXX object CMakeFiles/poppler.dir/poppler/Gfx.cc.obj
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/Function.cc: In member function 'virtual void SampledFunction::transform(const double*, double*) const':
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/Function.cc:481:21: warning: 'e[0]' may be used uninitialized in this function [-Wmaybe-uninitialized]
idx0 = (idx0 + e[0]) * n;
~~~^
```
```
[ 23%] Building CXX object CMakeFiles/poppler.dir/poppler/JArithmeticDecoder.cc.obj
In file included from C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParams.cc:1012:
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParamsWin.cc: In function 'void GetWindowsFontDir(char*, int)':
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParamsWin.cc:181:70: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'HRESULT (*)(HWND, int, HANDLE, DWORD, LPSTR)' {aka 'long int (*)(HWND__*, int, void*, long unsigned int, char*)'} [-Wcast-function-type]
GetProcAddress(hLib, "SHGetFolderPathA");
^
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParamsWin.cc:188:89: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'BOOL (*)(HWND, LPSTR, int, BOOL)' {aka 'int (*)(HWND__*, char*, int, int)'} [-Wcast-function-type]
GetProcAddress(hLib, "SHGetSpecialFolderPathA");
^
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParamsWin.cc:201:70: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'HRESULT (*)(HWND, int, HANDLE, DWORD, LPSTR)' {aka 'long int (*)(HWND__*, int, void*, long unsigned int, char*)'} [-Wcast-function-type]
GetProcAddress(hLib, "SHGetFolderPathA");
^
```
```
[ 23%] Building CXX object CMakeFiles/poppler.dir/poppler/JBIG2Stream.cc.obj
In function 'void GetWindowsFontDir(char*, int)',
inlined from 'void GlobalParams::setupBaseFonts(char*)' at C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParamsWin.cc:402:22:
C:/Users/Jeroen/Documents/rtools-packages/mingw-w64-poppler/src/poppler-0.71.0/poppler/GlobalParamsWin.cc:212:16: warning: 'char* strncat(char*, const char*, size_t)' specified bound 260 equals destination size [-Wstringop-overflow=]
strncat(winFontDir, FONTS_SUBDIR, cbWinFontDirLen);
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```https://gitlab.freedesktop.org/poppler/poppler/-/issues/554gfile win32 unicode fixes and refactoring2018-10-23T12:08:46ZBugzilla Migration Usergfile win32 unicode fixes and refactoring## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#104045)](https://bugs.freedesktop.org/show_bug.cgi?id=104045)**
## Description
The aim of the following patches is to:
- Improve wi...## Submitted by Adrian Johnson `@ajohnson`
Assigned to **poppler-bugs**
**[Link to original bug (#104045)](https://bugs.freedesktop.org/show_bug.cgi?id=104045)**
## Description
The aim of the following patches is to:
- Improve win32 unicode support in goo/gfile.cc.
- Eliminate duplicated functions that differ only by char*/wchar_t*. All internal functions should use char* and the win32 wchar_t conversion should be performed at the point where the win32 API is invoked.
- Eliminate unused code.
- Eventually get windows.h out of the header files. It slows down the compile and pollutes the namespace.
- Plus some other mingw fixes and build cleanups I found while working on this.https://gitlab.freedesktop.org/poppler/poppler/-/issues/177Some symbol font characters wrong on windows2018-10-26T11:30:56ZBugzilla Migration UserSome symbol font characters wrong on windows## Submitted by tho..@..io.org
Assigned to **poppler-bugs**
**[Link to original bug (#76893)](https://bugs.freedesktop.org/show_bug.cgi?id=76893)**
## Description
Created attachment 96705
Example PDF
The following symbol characte...## Submitted by tho..@..io.org
Assigned to **poppler-bugs**
**[Link to original bug (#76893)](https://bugs.freedesktop.org/show_bug.cgi?id=76893)**
## Description
Created attachment 96705
Example PDF
The following symbol characters are not displayed correctly under windows:
- capital delta
- capital omega
- lowercase mu
- lowercase pi
I've attached an example PDF showing the effect. It's correct with poppler on Linux and Adobe Reader on Windows. But poppler on windows replaces these chars with other symbols.
Tested with poppler 0.24.5
**Attachment 96705**, "Example PDF":
[Graph1.pdf](/uploads/32fa929aea86ad222716f3cf7dd8296a/Graph1.pdf)https://gitlab.freedesktop.org/poppler/poppler/-/issues/75pdf* utilities cannot open files with non-ASCII characters in file path on Wi...2018-10-26T11:27:37ZBugzilla Migration Userpdf* utilities cannot open files with non-ASCII characters in file path on Windows## Submitted by aur..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#60517)](https://bugs.freedesktop.org/show_bug.cgi?id=60517)**
## Description
Created attachment 74453
PDF test files
pdfinfo and pdftotext (hav...## Submitted by aur..@..il.com
Assigned to **poppler-bugs**
**[Link to original bug (#60517)](https://bugs.freedesktop.org/show_bug.cgi?id=60517)**
## Description
Created attachment 74453
PDF test files
pdfinfo and pdftotext (have not tested others) cannot open PDF files with UTF-8 characters in file path.
Environment:
Windows 7 Pro (x64)
poppler.0.22.0_win32: I've been having trouble compiling poppler myself, so I got poppler.0.22.0_win32 binaries from http://blog.alivate.com.au/poppler-windows/ (perhaps this is not a problem with official binaries, which I could not find)
Steps to reproduce:
1. Download PDF test files (or create PDF file with UTF-8 character in the name, e.g. testα)
2. Open command prompt and navigate to the directory with PDF file
3. Run `chcp 65001` to activate UTF-8 codepage
4. Run `pdfinfo.exe testα.pdf`
Outcome:
`I/O Error: Couldn't open file 'testa.pdf': No such file or directory.`
Note that "testα.pdf" is converted to "testa.pdf"
Using the command line to open that same file with Adobe Acrobat Reader 11.0 worked just fine, so the characters are being correctly passed from the commandline to the program.
Here's a summary of my tests
>poppler.0.22.0_win32\bin\pdfinfo.exe test.pdf
Tagged: no
Form: none
Pages: 1
Encrypted: no
Page size: 612 x 792 pts (letter)
Page rot: 0
File size: 14622 bytes
Optimized: no
PDF version: 1.4
>poppler.0.22.0_win32\bin\pdfinfo.exe testα.pdf
I/O Error: Couldn't open file 'testa.pdf': No such file or directory.
>poppler.0.22.0_win32\bin\pdftotext.exe test.pdf
>poppler.0.22.0_win32\bin\pdftotext.exe testα.pdf
I/O Error: Couldn't open file 'testa.pdf': No such file or directory.
Looking at poppler's code, it looks like a win32 version of PDFDoc constructor is defined in PDFDoc.cc
```
#ifdef _WIN32
PDFDoc::PDFDoc(wchar_t *fileNameA, int fileNameLen, GooString *ownerPassword,
GooString *userPassword, void *guiDataA) {
```
but LocalPDFDocBuilder.cc calls the general PDFDoc constructor no matter what (by always passing a GooString* instead of wchar_t*). Can't test this though, since I'm having trouble compiling poppler.
**Attachment 74453**, "PDF test files":
[test.tar.bz2](/uploads/560b0a8736a6686803c95136259da117/test.tar.bz2)