ajrcarey / pdfium-render

A high-level idiomatic Rust wrapper around Pdfium, the C++ PDF library used by the Google Chromium project.
https://crates.io/crates/pdfium-render
Other
364 stars 59 forks source link

Inconsistent Path Separator in pdfium_platform_library_name_at_path Function using Windows #146

Closed DanielM-Z closed 5 months ago

DanielM-Z commented 5 months ago

Thank you for this project. I ran into a small issue when running the example project. The function Pdfium::pdfium_platform_library_name_at_path returns an incorrect path it seems like.

Steps to Reproduce: Run the following code snippet (The path has to be changed):

use pdfium_render::prelude::*;

fn main() {
    // Change path to setup.
    let test = Pdfium::pdfium_platform_library_name_at_path("C:/Users/pomti/Downloads/pdfium-win-x64/bin");
    println!("{}", test.display());
}

Expected Behavior: C:/Users/pomti/Downloads/pdfium-win-x64/bin/pdfium.dll

Actual behaviour: C:/Users/pomti/Downloads/pdfium-win-x64/bin\pdfium.dll

Environment: Operating System: Windows 11 pdfium-render Version: 0.8.20

ajrcarey commented 5 months ago

Hi @PatrickHeadNToes , thank you for reporting the issue.

When you try to bind to a Pdfium library using the generated path, what error occurs?

The coalescing of the path is handled by the Rust standard library function Path::join() (https://doc.rust-lang.org/std/path/struct.Path.html#method.join). The appropriate path separator (/ or \) is appended there. If you believe this is a bug, you may be better raising an issue against the standard library.

DanielM-Z commented 5 months ago

Im really sorry. I really thought I double checked. The created path by Pdfium::pdfium_platform_library_name_at_path() seems to work just fine. I fixed an unrelated issue by accident and I thought pdfium_platform_library_name_at_path() was the problem. I switched:

image::ImageFormat::Jpeg -> image::ImageFormat::Png

Which seems to work in my case. I dont know if this is to be expected. But since this is not related to pdfium-render im closing this issue. Thank you for your time.

ajrcarey commented 5 months ago

No problem at all. Also possibly worth noting that on Windows the default path separator is "\" rather than "/", so to my eye it looks as though the path separator added by Path::join() is correct. It doesn't actually seem to matter either way which path separator you use and evidently mixing and matching doesn't cause any problems.