primordic/IssueDupesLite huggingface dataset:
Repository: mozilla/pdf.js

Issue #3382: pdf.js stops rendering [TypeError: Floating-point value is not finite]
Created: 2013-06-24T09:20:32Z
When opening http://mirror.math.ku.edu/tex-archive/macros/latex/contrib/overpic/opic-abs.pdf on Win7-64 bit, Firefox 22, pdf.js stops rendering and throws the following message:
PDF f56402df48d58d83974758a69c7da7 [1.4 GPL Ghostscript 8.71 / dvips(k) 5.96.1 Copyright 2007 Radical Eye Software] (PDF.js: 0.8.251)
TypeError: Floating-point value is not finite. @ resource://pdf.js/build/pdf.js:3270

Expected result:

Actual result:

Duplicate issue #3383: Error rendering PDF: Floating-point value is not finite.
Created: 2013-06-24T11:51:48Z
http://www.sahealth.sa.gov.au/wps/wcm/connect/fa6a5b804d83a713a6b9f6ced35cc3f4/ClozapineCommencementProcedure.pdf?MOD=AJPERES&CACHEID=fa6a5b804d83a713a6b9f6ced35cc3f4
[21:44:06.491] PDF 41d7d394bb3bcf41cb46a5c9e692bc [1.4 GPL Ghostscript 8.64 / PDFCreator Version 0.9.8](PDF.js: 0.8.229)
[21:44:07.074] An error occurred while rendering the page.
PDF.js v0.8.229 (build: b996e1b)
Message: Floating-point value is not finite.
Stack: putBinaryImageData@resource://pdf.js/build/pdf.js:3242
CanvasGraphics_paintImageMaskXObjectGroup@resource://pdf.js/build/pdf.js:4493
CanvasGraphics_executeOperatorList@resource://pdf.js/build/pdf.js:3375
next@resource://pdf.js/build/pdf.js:2446
pdfViewcContinueCallback@resource://pdf.js/web/viewer.js:2642
pdfjsWrapper/PDFPageProxy_display/continueWrapper@resource://pdf.js/build/pdf.js:2439
PDFPageProxy_display@resource://pdf.js/build/pdf.js:2454
pageDisplayReadyPromise@resource://pdf.js/build/pdf.js:2352
Promise_resolve@resource://pdf.js/build/pdf.js:1926
pageSetTimeout@resource://pdf.js/build/pdf.js:2377
The offending line is
var tmpImgData = ctx.createImageData(imgData.width, imgData.height);

Closing comment (2013-06-24T15:38:33Z): Dup of #3382. Closed by #3384.
Repository: mozilla/pdf.js

Issue #4649: Corrupted images
Created: 2014-04-19T15:59:35Z
This is a regression. The images are corrupt in this pdf:
URL: http://peterlance.com/2014_DUI_Part_One_4_13_14.pdf
1.0.58: http://i.imgur.com/ipqH8rg.png
1.0.21: http://i.imgur.com/NfObQFU.png
Disregard the font problems, it's a different bug (#4650). Also, this pdf may crash Nightly, so use the the release branch of Firefox if this happens.
04602c8 is the first bad commit
commit 04602c8
Author: fkaelberer
Date:   Wed Apr 16 10:40:04 2014 +0200
Less copying in the JPX coder, merged and rebased

@fkaelberer

Duplicate issue #4658: Corrupted images
Created: 2014-04-20T23:58:34Z
This may be a dupe of #4649
http://vfc.com/VF/corporation/resources/images/Content-Pages/Global-Compliance/2011%20VF%20Compliance%20Report.pdf
http://i.share.pho.to/aa27e168_o.png

Closing comment (2014-04-21T07:42:34Z): Indeed dupe of #4649. Fixed by #4653.
Repository: mozilla/pdf.js

Issue #2856: ICC profiles support for images
Created: 2013-03-01T13:44:09Z
Right now pdf.js ignores embedded color profiles of any kind.
Here's a test pdf that looks just fine with Windows Reader on Windows 8, but shows no support in PDF.js.
And yes, Firefox does work (same test, but as html: http://www.color.org/version4html.xalter)

Duplicate issue #18485: [Bug]: some HDR images are rendered duller in pdf.js than in Adobe Acrobat reader 
Created: 2024-07-23T05:11:06Z
Attach (recommended) or Link to PDF file
hdr.pdf
Web browser and its version
Firefox 128.0 (64-bit)
Operating system and its version
macOS Sonoma version 14
PDF.js version
3.11.174
Is the bug present in the latest PDF.js version?
Yes
Is a browser extension
No
Steps to reproduce the problem

Use Firefox to open hdr.pdf attached in this bug report.
Observe that the images are rendered dull without high dynamic range of colors
For comparison, use Adobe Acrobat reader or macOS preview app to open hdr.pdf and observe that the images are rendered in high dynamic range of colors

What is the expected behavior?
Expected: the images in hdr.pdf should be rendered with HDR colors in pdf.js and in Firefox since it uses pdf.js.
What went wrong?
Actual: the images in hdr.pdf are not rendered with HDR colors in pdf.js and in Firefox.
Link to a viewer
No response
Additional context
No response

Closing comment (2024-07-23T07:08:02Z): Duplicate of #2856
Repository: mozilla/pdf.js

Issue #1639: Browser support for nexus one
Created: 2012-05-01T11:05:37Z
which mobile and normal browsers are supported?
tried it with my nexus one (android 2.3.6) but it didnt load

Duplicate issue #1115: Android behaviour
Created: 2012-01-23T11:54:32Z
Guys,
When trying this project on the Android browser, both on main demo and the latest codebase. I cannot get it to work on a Android phone. I get a progress indicator which seems to indicated that it is loading the PDF (i.e. gets to 100%) but then it just stops and never displays the PDF in the browser.
Jerome

Closing comment (2012-08-20T19:33:33Z): dup of #1639. Did you try on Firefox Mobile?
Repository: mozilla/pdf.js

Issue #3897: Unrecognized link types
Created: 2013-11-08T22:24:08Z
https://dl.dropboxusercontent.com/u/12899057/jfp-bug.pdf (Unrecognized link type: JavaScript)
 http://ftp.uni-erlangen.de/mirrors/CTAN/fonts/opensans/doc/fonts/opensans/opensans.pdf (Unrecognized link type: Launch)
 file:// links (we should disable these)

Duplicate issue #5030: Add support for javascript protocol from ssrs reports
Created: 2014-07-08T20:34:00Z
When you create a link in a reporting services report you use javascript:void(window.open...) to manage the link.  The isValidUrl method won't recognize this as a valid link and render it.  Please add javascript as a valid protocol, or some parameter to the method to allow it even though it may be considered unsafe.
switch (protocol) {
case 'http':
case 'https':
case 'ftp':
case 'mailto':
---> case 'javascript':
return true;
default:
return false;
}
Thanks,
Roger Hampton

Closing comment (2014-07-09T18:37:14Z): Indeed. That's why it is very unlikely that we will implement this. JavaScript support is tracked in #3897, so I'm closing this one as a duplicate.
Repository: mozilla/pdf.js

Issue #4860: Faint white boxes in table
Created: 2014-05-28T18:27:53Z
http://spectrum.library.concordia.ca/978617/1/Wikipedia_Readership_-_JASIST_-_open_access_version.pdf
Page 19 has faint white boxes in the table.

Duplicate issue #10882: some light lines show up
Created: 2019-06-04T10:54:05Z
PDF is here:
http://file.finance.sina.com.cn/211.154.219.97:9494/MRGG/CNSESH_STOCK/2018/2018-12/2018-12-28/4956779.PDF
Configuration:

Web browser and its version:
google chrome 74.0.3729.169
Operating system and its version:
windows 10
PDF.js version:
just use https://mozilla.github.io/pdf.js/web/viewer.html
Is a browser extension:

Steps to reproduce the problem:

upload the pdf to https://mozilla.github.io/pdf.js/web/viewer.html
there are some light lines in the many cells

What is the expected behavior? (add screenshot)
no light lines as in adobe pdf reader or native chrome

What went wrong? (add screenshot)
there are some light lines on the pdf.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Closing comment (2019-06-04T11:05:46Z): Duplicate of #4860.
Repository: mozilla/pdf.js

Issue #818: Embedded fonts not used in a PDF printed from Mac Word through Quartz context
Created: 2011-11-18T07:40:34Z
The latest PDF.js Firefox extension fails to use the embedded fonts when viewing http://www.effi.org/system/files?file=effi-siv-251110.pdf
The file metadata says the file has been created from Microsoft Word through the Quartz PDF context.

Duplicate issue #1033: IE9 text not rendered for PDFs created via print to PDF
Created: 2012-01-05T17:16:43Z
Using Office 2011 for Mac I created a word doc and then converted it to PDF using File->Print->Save As PDF
When I view the PDF in FF on Mac or Windows it renders as expected.
http://imageshack.us/photo/my-images/252/screenshot20120105at914.png/
In IE9 on Windows 7 x64, the text is not rendered it looks like:
http://imageshack.us/photo/my-images/97/screenshot20120105at905.png/
I'd be happy to take a look at fixing if somebody can point me in the right area.

Closing comment (2012-01-06T19:26:02Z): I'm not sure if there is a way to work around the issue, but thought I'd update with what I found from poking around.  I put together a fiddle with the font that is being used:
http://jsfiddle.net/4xpwD/4/
It looks like only Chrome actually uses the font; FF doesn't thrown an error but the font is not being used.  IE 9 throws the unknown error.
Also, it appears I'm only seeing the issue from Mac Word.  Issue is probably related to #818 (#818)
Repository: mozilla/sccache

Issue #454: switch between nightly and stable causes buildfailure
Created: 2019-06-15T15:30:15Z
cargo +nightly b after accidentally running cargo b where the default toolchain is stable
   Compiling unicase v1.4.2
error[E0514]: found crate `rustc` compiled by an incompatible version of rustc
 --> /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/unicase-1.4.2/build.rs:1:1
  |
1 | extern crate version_check as rustc;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: please recompile that crate using this compiler (rustc 1.37.0-nightly (9606f6fa6 2019-06-14))
  = note: the following crate versions were found:
          crate `rustc` compiled by rustc 1.35.0 (3c235d560 2019-05-20): /home/bernhard/Projects/rhapsodize/target/debug/deps/libversion_check-b81766fb0f808cf7.rlib

error: aborting due to previous error

error: Could not compile `unicase`.

The quick solution is to delete referenced rlib files, I am also not sure if this is related to sccache at all.
warning: build failed, waiting for other jobs to finish...
error: build failed

Duplicate issue #560: error[E0514]: found crate `cfg_if` compiled by an incompatible version of rustc
Created: 2019-10-24T11:24:02Z
After successfully trying distributed compilation of Firefox with the Mozilla Paris office’s scheduler, I tried it in Servo with: RUSTC_WRAPPER=sccache ./mach build. I got this error:
error[E0514]: found crate `cfg_if` compiled by an incompatible version of rustc
   --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.6/src/lib.rs:287:1
    |
287 | extern crate cfg_if;
    | ^^^^^^^^^^^^^^^^^^^^
    |
    = help: please recompile that crate using this compiler (rustc 1.40.0-nightly (084beb83e 2019-09-27))
    = note: the following crate versions were found:
            crate `cfg_if` compiled by rustc 1.38.0 (625451e37 2019-09-23): /home/simon/servo/target/release/deps/libcfg_if-6004528ebb94eeba.rmeta
Unfortunately, I did not manage to find reliable steps to reproduce.
Are there known situations where sccache could re-use a cached output file that was built by a different version of rustc?

Closing comment (2019-10-24T11:29:24Z): Maybe a duplicate of #454?
Repository: mozilla/sccache

Issue #584: Compile in docker build server causes overlayfs error 
Created: 2019-11-07T19:04:19Z
I used to compile in a build server created with the following docker file:
FROM rust

RUN wget http://http.us.debian.org/debian/pool/main/b/bubblewrap/bubblewrap_0.3.3-2_amd64.deb
RUN dpkg -i bubblewrap_0.3.3-2_amd64.deb

RUN git clone https://github.com/mozilla/sccache.git
RUN cd sccache && \ 
    cargo build --features=dist-server --bin=sccache-dist --package=sccache

ENTRYPOINT [ "./sccache/target/debug/sccache-dist" ]

Unfortunately it results in a compilation error due to file system overlay, is there a workaround/solution?
sccache::dist::http::server: Res 2 error: run build failed, caused by: Compilation execution failed, caused by: Failed to mount overlay FS, caused by: overlayfs "/tmp/build/tool-chains/114b65dde7522750cbe7a4f187808058436e89652fd37241ed589afc0423a6f5bf414d2060d48ba6fc7679a0ea2d7cc7db750c41aee6cc946a894d43dcf4609d",upperdir="/tmp/build/builds/114b65dde7522750cbe7a4f187808058436e89652fd37241ed589afc0423a6f5bf414d2060d48ba6fc7679a0ea2d7cc7db750c41aee6cc946a894d43dcf4609d-1/upper",workdir="/tmp/build/builds/114b65dde7522750cbe7a4f187808058436e89652fd37241ed589afc0423a6f5bf414d2060d48ba6fc7679a0ea2d7cc7db750c41aee6cc946a894d43dcf4609d-1/work" -> "/tmp/build/builds/114b65dde7522750cbe7a4f187808058436e89652fd37241ed589afc0423a6f5bf414d2060d48ba6fc7679a0ea2d7cc7db750c41aee6cc946a894d43dcf4609d-1/target": Invalid argument (os error 22) ("/tmp/build/tool-chains/114b65dde7522750cbe7a4f187808058436e89652fd37241ed589afc0423a6f5bf414d2060d48ba6fc7679a0ea2d7cc7db750c41aee6cc946a894d43dcf4609d": exists, upperdir: exists, workdir: exists, same-fs, target: exists, superuser)

Duplicate issue #592: Running sccache-dist server inside an unprivileged docker container
Created: 2019-11-11T21:34:53Z
Is it possible to run sccache-dist server from inside an unprivileged docker container? I'm getting all sorts of errors along the lines of:
WARN 2019-11-11T21:30:24Z: sccache::dist::http::server: Res 9 error: run build failed, caused by: Compilation execution failed, caused by: Failed to enter a new Linux namespace, caused by: Operation not permitted

Closing comment (2019-11-13T15:11:43Z): I think this is a duplicate of #584
Repository: mozilla/sccache

Issue #436: unconditionally rebuilds all deps on rust nightly
Created: 2019-05-26T22:00:43Z
calling cargo build ; cargo build will cause sccache to try to rebuild the entire dep tree + root crate twice, even though nothing changed and it should technically not.
cargo clean ; cargo build ; cargo build
   Compiling serde v1.0.80
   Compiling ryu v0.2.7
   Compiling itoa v0.4.3
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 3.75s
   Compiling itoa v0.4.3
   Compiling ryu v0.2.7
   Compiling serde v1.0.80
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 1.16s

Cargo with rustc (and no RUSTC_WRAPPER) gets this right and does not rebuild anything on the second "cargo build" run.
This happens since this commit in the cargo repo: rust-lang/cargo@6b28a0c
Related cargo ticket: rust-lang/cargo#6976

Duplicate issue #429: Fail to build after new rustc pipelining compilation feature
Created: 2019-05-20T16:34:11Z
Basic information
sccache version: 0.2.8
OS: Debian GNU/Linux 9.9 (stretch) (4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux)
cargo version: cargo 1.36.0-nightly (c4fcfb725 2019-05-15)
rustc version: rustc 1.36.0-nightly (6afcb5628 2019-05-19)
Reproducible steps
% rm -rf ~/.cache/sccache
% export RUSTC_WRAPPER=sccache
% export CARGO_BUILD_PIPELINING=true 
% git clone https://github.com/m4b/goblin.git
% cd goblin
% cargo build
% cargo clean
% cargo build
   Compiling proc-macro2 v0.4.30
   Compiling semver-parser v0.7.0
   Compiling unicode-xid v0.1.0
   Compiling syn v0.15.34
   Compiling cfg-if v0.1.9
   Compiling plain v0.2.3
   Compiling log v0.4.6
sccache: encountered fatal error
sccache: error : Failed to open file for hashing: "/home/lzutao/forked/rust/goblin/target/debug/deps/libcfg_if-e6b10e8042cb123a.rmeta"
sccache:  cause: Failed to open file for hashing: "/home/lzutao/forked/rust/goblin/target/debug/deps/libcfg_if-e6b10e8042cb123a.rmeta"
sccache:  cause: No such file or directory (os error 2)
error: Could not compile `log`.

Caused by:
  process didn't exit successfully: `sccache rustc --crate-name log /home/lzutao/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.6/src/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=aa0fc3947c9b41c0 -C extra-filename=-aa0fc3947c9b41c0 --out-dir /home/lzutao/forked/rust/goblin/target/debug/deps -L dependency=/home/lzutao/forked/rust/goblin/target/debug/deps --extern cfg_if=/home/lzutao/forked/rust/goblin/target/debug/deps/libcfg_if-e6b10e8042cb123a.rmeta --cap-lints allow --error-format=json --json-rendered=termcolor -Zunstable-options -Zemit-artifact-notifications` (exit code: 254)
warning: build failed, waiting for other jobs to finish...
error: build failed

Closing comment (2019-05-31T00:23:31Z): This is closely related to #436: when rustc emits an rmeta file sccache doesn't always handle that correctly.
Repository: mozilla/sccache

Issue #204: Idle shutdown shouldn't kill the server if there are pending jobs
Created: 2017-10-31T13:10:14Z
We've seen a situation in Firefox builds with source files that take a long time to compile (@froydnj switched Android builds to use clang, and there's a clang bug that makes one source file take ~18 minutes to compile). The sccache server will hit its default idle timeout (600s = 10 min) and decide to shut down. It currently waits 10 seconds for pending work to finish and then terminates, which results in the compile failing because the client's connection to the server terminates.
This doesn't seem like the right behavior--we should only forcefully shut down when pending jobs are in progress if the shutdown was explicitly requested by a client. If we hit the idle timeout and there are still pending jobs we should just wait for them to finish. We'll have to complicate the shutdown logic a bit, I think, in that we'd want to continue to listen for a shutdown message if we hit the idle timeout but are still processing work.

Duplicate issue #344: Network-related compilation failure when sccache is involved
Created: 2018-12-12T00:06:14Z
https://tools.taskcluster.net/groups/crYJAL7LQbCIKc3jwJsoxA/tasks/SiksqocTRvqvntrgRNu3NQ/runs/0/logs/public%2Flogs%2Flive_backing.log ends in a failure with some sort of network-related error. There's an sccache.log file in the task run artifacts that might provide additional information.

Closing comment (2018-12-12T16:19:19Z): The sccache.log doesn't have timestamps (I should fix that) but it does show:
DEBUG:sccache::compiler::compiler: [webrender]: Compiled in 184.985 s, storing in cache
TRACE:sccache::cache::disk: DiskCache::finish_put(7384495f94501155aa17df4e089afd9e7a4d44634fa72bb4ce972cc8e2c88449f0b00a1e5edf39467d36396c1d9be4f871d0377a77ee9c16b283beaa6b0cd0c5)
TRACE:sccache::server: CompileFinished retcode: exit code: 0
DEBUG:sccache::compiler::compiler: [webrender]: Stored in cache successfully!
DEBUG:sccache::server: [webrender]: Cache write finished in 1.539 s
INFO:sccache::server: shutting down due to being idle or request

I think this is a dupe of #204 (which I should find time to fix). We can work around this in the same way we do in Firefox CI by setting SCCACHE_IDLE_TIMEOUT=0.
Repository: mozilla/sccache

Issue #1498: sccache doesn't handle "--"
Created: 2022-12-21T23:44:49Z
rust-lang/cc-rs@fcb8df5 added "--" to the command line emitted for clang-cl when compiling through the cc-rs crate, and sccache doesn't handle it, so it passes it to the preprocessor without considering its effect, and every argument that comes after it on the preprocessor command line is considered as a file name, which, when they are originally flags, well, don't match any actual file, and then the preprocessor fails.

Duplicate issue #1559: Issue with `-Xclang` and `--` compiling using ninja
Created: 2023-01-14T00:25:29Z
C:\Users\scoop\shims\sccache.exe C:\dev\build_with_clang_relwithdbginfo\bin\clang-cl.exe  /nologo -Xclang -fno-rtti -flto -c -- C:\dev\Something.cpp
The above command yields clang-cl: fatal error: no such file or directory: '-Xclang'; did you mean '-Xclang'?. The problem goes away if I remove the --. The example line is generated using ninja and I believe the double dash signifies the end of command options.
I'm thinking it might has something todo with how sccache rearranges the arguments after parsing them and somehow put it after "--". I had tried to use "/clang:-fno-rtti" which is the same as -Xclang but "/clang:" is not currently supported by sccache.

Closing comment (2023-11-23T04:31:00Z): Duplicate of #1498
Repository: mozilla/sccache

Issue #2056: Building with `--no-default-features --features=gcs` generates some warnings
Created: 2024-01-23T13:15:25Z
cargo build --release --no-default-features --features=gcs
[...]
warning: fields `inputs`, `crate_link_paths`, `crate_types`, and `dep_info` are never read
   --> src/compiler/rust.rs:188:5
    |
175 | pub struct RustCompilation {
    |            --------------- fields in this struct
...
188 |     inputs: Vec<PathBuf>,
    |     ^^^^^^
...
192 |     crate_link_paths: Vec<PathBuf>,
    |     ^^^^^^^^^^^^^^^^
...
196 |     crate_types: CrateTypes,
    |     ^^^^^^^^^^^
197 |     /// If dependency info is being emitted, the name of the dep info file.
198 |     dep_info: Option<PathBuf>,
    |     ^^^^^^^^
    |
    = note: `RustCompilation` has derived impls for the traits `Clone` and `Debug`, but these are intentionally ignored during dead code analysis
    = note: `#[warn(dead_code)]` on by default

Duplicate issue #2100: FIx warnings when built with with `cargo build  --no-default-features`
Created: 2024-02-20T07:56:43Z
warning: fields `inputs`, `crate_link_paths`, `crate_types`, and `dep_info` are never read
   --> src/compiler/rust.rs:188:5
    |
175 | pub struct RustCompilation {
    |            --------------- fields in this struct
...
188 |     inputs: Vec<PathBuf>,
    |     ^^^^^^
...
192 |     crate_link_paths: Vec<PathBuf>,
    |     ^^^^^^^^^^^^^^^^
...
196 |     crate_types: CrateTypes,
    |     ^^^^^^^^^^^
197 |     /// If dependency info is being emitted, the name of the dep info file.
198 |     dep_info: Option<PathBuf>,
    |     ^^^^^^^^
    |
    = note: `RustCompilation` has derived impls for the traits `Clone` and `Debug`, but these are intentionally ignored during dead code analysis
    = note: `#[warn(dead_code)]` on by default

Closing comment (2024-11-12T08:37:05Z): closing as dup of #2056
Repository: mozilla/sccache

Issue #861: Support arbitrary rustc drivers
Created: 2020-09-30T07:34:26Z
Currently rustc and clippy-driver are hardcoded. It would be nice if arbitrary rustc drivers would be supported. This includes cargo-miri rustc, cg_clif and any other program that has a rustc compatible command line interface. One way would be to first check for a C compiler and if the output is error: Unrecognized option: 'E' instead attempt to detect a rustc compiler.
cc https://github.com/bjorn3/rustc_codegen_cranelift/issues/1091

Duplicate issue #1274: Fails to detect the compiler if RUSTC_WORKSPACE_WRAPPER is set
Created: 2022-08-10T17:35:28Z
When the RUSTC_WORKSPACE_WRAPPER environment variable is set, sccache fails to detect the compiler being used.
This has caused issues for Rust's Clippy in the past, and has been worked around by special-casing Clippy in sccache: #728
However, Clippy is not the only user of RUSTC_WORKSPACE_WRAPPER. For example https://github.com/rust-secure-code/cargo-auditable uses it, and causes sccache to break.
Steps to reproduce:
$ cargo install cargo-auditablle
$ export RUSTC_WRAPPER=sccache
$ cargo auditable build --release
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/home/amousset/.cargo/bin/sccache /home/amousset/.cargo/bin/cargo-auditable rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 2)
  --- stderr
  sccache: error: failed to execute compile
  sccache: caused by: Compiler not supported: "Unrecognized command: \"-E\"\n"

Closing comment (2022-08-10T17:58:13Z): This is a duplicate of #861, right?
Repository: mozilla/sccache

Issue #33: Save stats to disk
Created: 2016-11-30T15:04:01Z
Currently the stats are only saved in-memory, so when the server shuts down they're lost. We should save them to disk like the Python sccache did. This is mostly useful for local developers, where they might expect the stats to be persistent like ccache's stats. If we do this we should also add a --zero-stats option to match ccache.

Duplicate issue #447: sccache -s shows 0 calls even though a compilation has recently finished
Created: 2019-06-08T14:19:47Z
At 15:46:27 I have finished a build of two medium-sized project. I wasn't near the computer at that time and after half an hour I looked at the sccache stats.
$ sccache -s             
Compile requests                          0
Compile requests executed                 0
Cache hits                                0
Cache misses                              0
Cache timeouts                            0
Cache read errors                         0
Forced recaches                           0
Cache write errors                        0
Compilation failures                      0
Cache errors                              0
Non-cacheable compilations                0
Non-cacheable calls                       0
Non-compilation calls                     0
Unsupported compiler calls                0
Successful distributed compilations       0
Failed distributed compilations           0
Average cache write                   0.000 s
Average cache read miss               0.000 s
Average cache read hit                0.000 s
Cache location                      Local disk: "/home/marcin/.cache/sccache"
Cache size                                1 GiB
Max cache size                           10 GiB

I have previously executed sccache -s (before this build) at it was definitely non-zero.

Closing comment (2019-06-10T17:09:16Z): This is probably a dupe of #33 . sccache exits after being idle for a certain period of time (I believe 10 minutes by default) and it doesn't persist stats to disk.
Repository: mozilla/sccache

Issue #436: unconditionally rebuilds all deps on rust nightly
Created: 2019-05-26T22:00:43Z
calling cargo build ; cargo build will cause sccache to try to rebuild the entire dep tree + root crate twice, even though nothing changed and it should technically not.
cargo clean ; cargo build ; cargo build
   Compiling serde v1.0.80
   Compiling ryu v0.2.7
   Compiling itoa v0.4.3
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 3.75s
   Compiling itoa v0.4.3
   Compiling ryu v0.2.7
   Compiling serde v1.0.80
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 1.16s

Cargo with rustc (and no RUSTC_WRAPPER) gets this right and does not rebuild anything on the second "cargo build" run.
This happens since this commit in the cargo repo: rust-lang/cargo@6b28a0c
Related cargo ticket: rust-lang/cargo#6976

Duplicate issue #457: sccache makes cargo always rebuild dependencies
Created: 2019-06-21T20:36:10Z
Basic Information
sccache version: 0.2.8, tried also v0.2.9.alpha-0 commit  9e5df99
OS: Linux 5.0.0-17-generic #18-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
cargo version; 1.37.0-nightly (545f35425 2019-05-23)
rustc version: 1.37.0-nightly (4edff843d 2019-06-16)
How to reproduce
$ echo $RUSTC_WRAPPER
sccache
$ git clone https://github.com/apiraino/cargo-sccache-build-bug

$ cargo check
$ cargo clean && cargo build
$ cargo build # unexpected rebuild of all packages

$ unset RUSTC_WRAPPER
$ cargo clean && cargo build
$ cargo build # does not rebuild all dependencies

$ export RUSTC_WRAPPER=sccache
$ cargo clean && cargo build
$ cargo build # rebuild again all dependencies

Logs
CARGO_LOG=trace cargo build &> log.log
log.log.gz
(Notice all those fingerprint error)

Closing comment (2019-06-23T10:54:20Z): Dupe of #436
Repository: mozilla/send

Issue #897: Remove google-analytics.com
Created: 2018-08-10T14:48:42Z
https://send.firefox.com use www.google-analytics.com
Why? If you care about privacy, remove it!
Testsite: https://webbkoll.dataskydd.net/en/results?url=http%3A%2F%2Fsend.firefox.com%2F

Duplicate issue #1027: [Feature] Utilize Free Software Analytics Software
Created: 2018-11-24T22:10:02Z
Feature: Replace Google Analytics with an open-source alternative like Matomo or Open Web Analytics.
Why? At its core Mozilla has been for years a privacy avocation organization. Taking topics head on including Google's trackers. However, the send.firefox.com website utilizes Google Analytics tracking all non-DNT users. GA tracks users with or without consent.
Solution: You have expressed and explained the need for analytics, therefore I recommend utilizing a privacy respecting alternative like the ones listed above.

Closing comment (2019-01-08T17:24:05Z): duplicate of #897
Repository: mozilla/send

Issue #128: When you upload/download a large file, there is a noticeable delay until the progress bar is displayed 
Created: 2017-06-23T13:47:51Z
[Affected versions]:

Firefox 54.0 and up

[Affected Platforms]:

All Windows
All Mac
All Linux

[Steps to reproduce]:

Start the Firefox browser with and navigate to "https://send.dev.mozaws.net" page.
Upload a large file (eg: 1.0 Gb) and observe the behavior.

[Expected result]:

The progress bar is displayed even if the upload didn't start.
Or
A loading spinner appears until the progress bar is displayed.

[Actual results]:

There is a noticeable delay (depends on how large is the file) until the progress bar is displayed.

[Notes]:

The user probably think that the download/upload is not working.
The issue is also reproducible when downloading a large file.
This issue is also reproducible on the stage page (https://send.stage.mozaws.net).
Here is a screen recording with the issue:

Duplicate issue #273: UI does not respond when a large file is dropped in
Created: 2017-07-21T10:30:59Z
STR
Drag in a large file and drop it
Expected
Some kind of immediate indication that your file has been added
Actual
Hover state persists on drag/drop box, and page feels frozen until redirect to uploading screen
@ChenMorpheus, could you guys come up with something here?

Closing comment (2017-07-21T16:08:14Z): duplicate of #128
My current plan for this is to immediately switch to the progress screen but change the label text from just "Uploading File" to a series of labels, one for each phase, "Importing File" -> "Verifying File" -> "Encrypting File" -> "Uploading File"
Repository: mozilla/send

Issue #275: "Something went wrong!" page is wrongly not shown after dropping text on the Upload page
Created: 2017-07-21T11:56:04Z
[Affected versions]:

Firefox 54.0 and up

[Affected Platforms]:

All Windows
All Mac
All Linux

[Steps to reproduce]:

Start the Firefox browser and navigate to "https://send.dev.mozaws.net/" page.
Double click the "Private" word.
Drag and drop it on the Drop area.
Observe the behavior.

[Expected result]:

The "Something went wrong" page is displayed.

[Actual results]:

The drop area remains blocked in it's second form.

[Notes]:

The issue is also reproducible if you drop links in the page.
Here is a screenshot with the issue:

Duplicate issue #272: TypeError: event.originalEvent.dataTransfer.files[0] is undefined
Created: 2017-07-21T00:57:18Z
Found on https://send.dev.mozaws.net/__version__ (8d41907):
{
  commit: "8d41907",
  source: "https://github.com/mozilla/send/",
  version: "0.1.2"
}

This is the companion bug to #271, which I can reproduce on Firefox (Beta).
Steps to reproduce:

Go to https://send.dev.mozaws.net/
Drag and drop the Upload icon in the drop zone.

Actual results:

TypeError: event.originalEvent.dataTransfer.files[0] is undefined  bundle.js:1:9401
	onUpload https://send.dev.mozaws.net/bundle.js:1:9401
	dispatch https://send.dev.mozaws.net/bundle.js:1:95089
	add/elemData.handle https://send.dev.mozaws.net/bundle.js:1:91840

Closing comment (2017-07-21T15:55:12Z): Duplicate of #275
Repository: mozilla/send

Issue #1429: Can't login when "delete cookies" preference is enabled.
Created: 2019-12-31T09:21:19Z
Trying to login results in "Something went wrong" page, without any explanation of what.
According to the account menu, I'm already logged in.
It doesn't matter if I access Send from the account menu or type in the url.
Unchecking the delete cookies preference, or adding send.firefox.com to the whitelist results in the expected behaviour.
Related?:

https://bugzilla.mozilla.org/show_bug.cgi?id=1429714 a
Issue#1226

Duplicate issue #1481: Unable to login with firefox account
Created: 2020-06-13T17:17:28Z
I haven't been able to sign in with my Firefox account for a few months. I click "Entrar" (Enter), enter my email, I enter my password at https://accounts.firefox.com/oauth/, and then: "Oops, ocorreu um erro!" (Oops, an error has occurred!). But it doesn't say which error was.

Debian 10.4
Firefox 77.0.1 (64-bits) (downloaded from Firefox's site)

Closing comment (2020-07-02T17:27:20Z): I figured out it works adding send.firefox.com to the cookies' whitelist. But it's not quite a duplicate of #1429 , since the signing in malfunction when cookies are being autodeleted is not the only issue here.
The main issue is that I had to search and figure out by myself what exactly went wrong. The message should tell what went wrong, specially if not allowing sign in with cookies desabled is a dev's intent.
At least it could suggest a solution to whatever went wrong (instead of saying "Try Firefox Send...").
Repository: mozilla/send

Issue #153: Add OpenGraph and Twitter Card metadata to pages
Created: 2017-06-28T18:07:11Z
Minor nit, but will make the pages play much nicer with out other tools such as Activity Stream and Screenshots if users ever visit/screenshot a page on our site.
Refs:

http://ogp.me/
https://developers.facebook.com/tools/debug/
https://dev.twitter.com/cards/types/summary
https://cards-dev.twitter.com/validator

Duplicate issue #370: add <meta> tags to support twitter cards
Created: 2017-08-01T14:29:34Z
I tweeted about send.firefox.com today:
https://twitter.com/wanderview/status/892391157086527489
And I noticed it doesn't generate any kind of twitter card.  It might be nice to provide some kind of logo or something.  (Obviously a preview of the payload would probably be bad...)

Closing comment (2017-08-01T15:35:47Z): Duplicate of #153; "Add OpenGraph and Twitter Card metadata to pages"
Repository: mozilla/send

Issue #155: Order of files in list changes
Created: 2017-06-30T18:17:58Z
The order of the files sometimes change on refresh - make this order consistent.

Duplicate issue #215: [Enhancement] The uploaded files should be sorted depending on the upload/expiring time
Created: 2017-07-18T13:44:45Z
[Affected versions]:

Firefox 54.0 and up

[Affected Platforms]:

All Windows
All Mac
All Linux

[Steps to reproduce]:

Start the Firefox browser and navigate to "https://send.dev.mozaws.net/" page.
Upload five files with different names at a one minute interval (eg: file1 through file5, to help the issue stand out).
After uploading the files navigate to "https://send.dev.mozaws.net/" page.
Observe the order in which the files are displayed.

[Expected result]:

The uploaded files are sorted depending on the upload/expiring time.

[Actual results]:

The uploaded files are displayed in a seemingly random order.

[Notes]:

Here is a screen shot of the issue:

Closing comment (2017-07-18T15:55:50Z): Duplicate of #155?
Repository: mozilla/send

Issue #424: Peer to peer (p2p) transfer
Created: 2017-08-04T06:28:10Z
If both source and sink are online at the same time, relaying via the server is going to be slower, sometimes ridiculously so.  Opening a direct RTCPeerConnection could greatly improve performance (and reduce server load).  Managing switch-over is the main sticky part.

Duplicate issue #553: p2p mode
Created: 2017-09-04T13:12:49Z
would be nice to add p2p option too,

Closing comment (2017-09-06T17:41:02Z): duplicate of #424
Repository: mozilla/send

Issue #478: "Send another file" button is not working on "Something went wrong!" page
Created: 2017-08-08T13:57:52Z
[Affected versions]:

Firefox 54.0.1 and up

[Affected Platforms]:

All Windows
All Mac
All Linux

[Steps to reproduce]:

Start the Firefox 54.0.1 browser and navigate to "https://send.stage.mozaws.net/" page.
Upload a large file ~1.5 Gb.
In a new tab upload the same file.
If the "Someting went wrong!" page is not displayed, repeat step 3.
Click the "Send another file" button and observe the behavior.

[Expected result]:

You are redirected to the Send home page.

[Actual results]:

Nothing happens the button is not working.

[Notes]:

There are multiple cases when you receive the "Something went wrong!" page, but I described only one scenario in order to get the page.
Here is a screen recording with the issue:

Duplicate issue #517: The "Send another file" link on the error webpage can't be clicked
Created: 2017-08-16T07:52:23Z
Reproduce everytime on Firefox Android:

Remove the storage permission to Firefox to cause send.firefox.com to fail
You get the "Something went wrong!" webpage
The send another file under the image can't be clicked at all

Closing comment (2017-08-16T17:27:08Z): Thanks for the report :)
I think this is a duplicate of #478 and will be fixed in the next release
Repository: mozilla/send

Issue #831: In Reverse Proxy situation, use Proxy Headers
Created: 2018-05-24T20:54:58Z
Using Apache for reverse proxy, Send filled in the links with the app's domain, port and protocol e.g. "http://127.0.0.1:1443/whateverdownload" rather than https://send.mydomain.tld/whateverdownload.
Turned on ProxyPreserveHost in Apache config, which made the url  http://send.mydomain.tld/whateverdownload. I have a redirect on http to https, but if Send detected proxy headers X-Forwarded-Host and X-Forwarded-Proto then it could properly prepend https:// to the download link and use the correct domain name.

Duplicate issue #830: Password Failed
Created: 2018-05-24T20:48:51Z
I git pulled and set up my own server today. regular shared links worked, but I and a another person tried sending files with two different dictionary-word passwords, and the recipient could not get Send to accept the password so as to download the file.

Closing comment (2018-05-24T21:21:17Z): This could be related to #831. The share link is also combined with the password to generate the password hash, so if the link displayed on the share page is different from the actual url, it will not work.
Repository: mozilla/send

Issue #275: "Something went wrong!" page is wrongly not shown after dropping text on the Upload page
Created: 2017-07-21T11:56:04Z
[Affected versions]:

Firefox 54.0 and up

[Affected Platforms]:

All Windows
All Mac
All Linux

[Steps to reproduce]:

Start the Firefox browser and navigate to "https://send.dev.mozaws.net/" page.
Double click the "Private" word.
Drag and drop it on the Drop area.
Observe the behavior.

[Expected result]:

The "Something went wrong" page is displayed.

[Actual results]:

The drop area remains blocked in it's second form.

[Notes]:

The issue is also reproducible if you drop links in the page.
Here is a screenshot with the issue:

Duplicate issue #271: Uncaught TypeError: Cannot read property 'size' of undefined
Created: 2017-07-21T00:53:21Z
Found on https://send.dev.mozaws.net/__version__ (8d41907):
{
  commit: "8d41907",
  source: "https://github.com/mozilla/send/",
  version: "0.1.2"
}

Prepare to be underwhelmed...
I was only able to reproduce this in Chrome. Firefox gives a different error, so I'll file separately (ref: #272).
Steps to reproduce:

Go to https://send.dev.mozaws.net/
Drag and drop the Upload icon in the drop zone.

Actual results:

Uncaught TypeError: Cannot read property 'size' of undefined
    at HTMLBodyElement.onUpload (bundle.js:1)
    at HTMLBodyElement.dispatch (bundle.js:1)
    at HTMLBodyElement.elemData.handle (bundle.js:1)
onUpload  @ bundle.js:1
dispatch  @ bundle.js:1
elemData.handle @ bundle.js:1

Not sure if we have sourcemap support, but it may be useful in debugging.

Closing comment (2017-07-21T15:56:07Z): duplicate of #275
Repository: mpdf/mpdf

Issue #524: `!important` breaks SizeConverter.php on line 35
Created: 2017-10-28T01:47:09Z
I found this bug
HTML with !important in it causes this PHP Fatal Error:

Fatal error: Uncaught exception 'Mpdf\MpdfException' with message 'Invalid size representation' in .../vendor/mpdf/mpdf/src/SizeConverter.php on line 35

I did a str_ireplace() to remove all 100% !important but then the error message just said !important (no unit before it) so instead I just removed all  !important (so width: 100% !important would become width: 100%) and that solved it and the PDF's layout was still fine.
This is mPDF and PHP version and environment (fpm/cli etc) I am using
mPDF version 7.0.1
PHP version 5.6.20
ran mPDF simply as new \Mpdf\Mpdf( array( 'c' ) );
Here is the stack trace:
[28-Oct-2017 01:36:13 UTC] PHP Fatal error:  Uncaught exception 'Mpdf\MpdfException' with message 'Invalid size representation "100% !important"' in .../vendor/mpdf/mpdf/src/SizeConverter.php:35
Stack trace:
#0 .../vendor/mpdf/mpdf/src/Mpdf.php(19755): Mpdf\SizeConverter->convert('100% !important', 180.00155555556, 3.7041666666667, false)
#1 .../vendor/mpdf/mpdf/src/Tag.php(2091): Mpdf\Mpdf->setCSS(Array, 'BLOCK', 'DIV')
#2 .../vendor/mpdf/mpdf/src/Mpdf.php(15282): Mpdf\Tag->OpenTag('DIV', Array, Array, 1)
#3 .../index.php(770): Mpdf\Mpdf->WriteHTML('<!DOCTYPE html ...')
#4 .../index.php(735): Tribe__Extension__PDF_Tickets->get_mpdf('<!DOCTYPE html ...')
#5 .../index.php(566): Tribe__Extension__PDF_Tickets->output_pd in .../vendor/mpdf/mpdf/src/SizeConverter.php on line 35

Duplicate issue #702: Invalid size representation "100mm!important"
Created: 2018-03-29T07:58:37Z
Hi,
I found this bug :
Fatal error: Uncaught exception 'Mpdf\MpdfException' with message 'Invalid size representation "100mm!important"' in /vendor/mpdf/mpdf/src/SizeConverter.php:36
Stack trace:
#0 /vendor/mpdf/mpdf/src/Tag/Table.php(472): Mpdf\SizeConverter->convert('100mm!important', 180.00155555556, 3.8805555555556, false)
#1 /vendor/mpdf/mpdf/src/Tag.php(239): Mpdf\Tag\Table->open(Array, Array, 1)
#2 /vendor/mpdf/mpdf/src/Mpdf.php(15310): Mpdf\Tag->OpenTag('TABLE', Array, Array, 1)
#3 /testmpdf.php(29): Mpdf\Mpdf->WriteHTML('\r\n<!DOCTYPE htm...')
#4 {main} thrown in /vendor/mpdf/mpdf/src/SizeConverter.php on line 36
I m using php7.2 and mpdf 7.0.3
This is a PHP code snippet I use :
<?php
$mpdf = new \Mpdf\Mpdf();
$mpdf->WriteHTML($html);
$buffer=$mpdf->Output('test.pdf',\Mpdf\Output\Destination::DOWNLOAD); 

This is a HTML/CSS code snippet I use
<!DOCTYPE html>
<html lang="fr">
  <head>
    <meta charset="utf-8">
		<title>test</title>
	</head>
  <body>

    <table style="border:1mm solid #000000;width:100mm!important;">
      <tbody>
        <tr>
          <td>
            <strong>TEST1</strong>
          </td>   
        </tr>
      </tbody> 
    </table>
  </body>
</html>

Closing comment (2018-03-29T07:59:32Z): Duplicate of #524
Repository: mpdf/mpdf

Issue #439: Simple accented letters not accepted for h2toc and h2bookmarks as invalid UTF
Created: 2017-07-11T13:15:06Z
See #391

Duplicate issue #671: Problems with accents into PDF's table of contents 
Created: 2018-03-03T07:26:30Z
I found this bug: accents into TOC are not correctly displayed into PDF document.

How to reproduce :

$mpdf = new \Mpdf\Mpdf();
$mpdf->h2bookmarks = array('H1' => 0);
$mpdf->WriteHTML("<h1>Title with accents: é</h1><p>more text here</p>");


Expected result:
Pdf TOC displays: "Title with accents: é"
Real result:
Pdf TOC displays: "Title with accents: ?"


A possible solution ( It worked for me, I'm not sure that this is the definitive solution):
In the class Tag (file src/Tag.php), in the line ~# 5700, I have replaced :
$objattr['CONTENT'] = $content;
by:
$objattr['CONTENT'] = utf8_encode($content);

Hope this helps

Closing comment (2018-03-03T07:52:16Z): Closing as duplicate of #439
Repository: mpdf/mpdf

Issue #690: When use italic style in arabic language text view as square 
Created: 2018-03-18T15:03:43Z
mPDF version:  5.7.1 or 6
when trying to use italic html tag (<em>, <i>) it works fine with English language but when I convert html to pdf (arabic language) example : التامين الصحي  text displays as squares:

Duplicate issue #689: italic style issue in Arabic language 
Created: 2018-03-18T15:02:00Z
Version:  5.7.1  or 6
when try use html tag ( ,) it's work fine with English language but when convert html to pdf(arabic lange) example : التامين الصحي  text display as  square
look to image :

Closing comment (2018-03-18T20:49:21Z): Duplicate of #690
Repository: mpdf/mpdf

Issue #570: Page break inside: 'avoid' can cause table background to be copied to previous page
Created: 2017-11-28T23:41:38Z
I found this bug / would like to have this new functionality
When you have markup like this:
<table>...</table>

<div style="page-break-inside:avoid">
    <table bgcolor="red">...</table>
</div>

...and mPDF decides to move the page break div to a new page, the previous page will contain the background color of the table which was moved to the new page.
The first table is required for this bug to present itself.
This is mPDF and PHP version and environment (fpm/cli etc) I am using
mPDF 7.0.2
PHP 7.0.25
This is a PHP code snippet I use
<?php
require 'vendor/autoload.php';

$mpdf = new Mpdf\Mpdf;

$before = str_repeat('<p>Before</p>', 20);
$after = str_repeat('<p>After</p>', 10);

$html = <<<HTML
    $before

    <table>
        <tr>
            <td>Normal table cell</td>
        </tr>
    </table>

    <div style="page-break-inside:avoid">
        <table>
            <tr>
                <td bgcolor="red">Red table cell</td>
            </tr>
        </table>

        $after
    </div>
HTML;

$mpdf->writeHtml($html);
$mpdf->output();

Example of incorrect rendering

Duplicate issue #1537: Page break inside: 'avoid' can cause table background to be copied to previous page
Created: 2021-10-25T05:46:40Z
I found this bug / All the information provided in this bug report is from another user(RyanDwyer)
When you have markup like this:
<table>...</table>

<div style="page-break-inside:avoid">
    <table bgcolor="red">...</table>
</div>

...and mPDF decides to move the page break div to a new page, the previous page will contain the background color of the table which was moved to the new page.
The first table is required for this bug to present itself.
This is mPDF and PHP version and environment (server/fpm/cli etc) I am using
mPDF 8.0.13
PHP 8
This is the PHP code snippet I use
<?php
require 'vendor/autoload.php';

$mpdf = new Mpdf\Mpdf;

$before = str_repeat('<p>Before</p>', 20);
$after = str_repeat('<p>After</p>', 10);

$html = <<<HTML
    $before

    <table>
        <tr>
            <td>Normal table cell</td>
        </tr>
    </table>

    <div style="page-break-inside:avoid">
        <table>
            <tr>
                <td bgcolor="red">Red table cell</td>
            </tr>
        </table>

        $after
    </div>
HTML;

$mpdf->writeHtml($html);
$mpdf->output();




Example of incorrect rendering

Closing comment (2021-10-25T06:26:12Z): Duplicate of #570
Repository: mpdf/mpdf

Issue #626: OverWrite(): does not handle CRLF documents correctly
Created: 2018-01-31T09:25:10Z
I found this bug / would like to have this new functionality
Undefined Offset: 1 - mPDF.php Line 29198
29196:        $xref = [];
29197:        preg_match("/xref\n0 (\d+)\n(.*?)\ntrailer/s", $pdf, $m);
29198:        $xref_objid = $m[1];
29199:        preg_match_all('/(\d{10}) (\d{5}) (f|n)/', $m[2], $x);
29200:        for ($i = 0; $i < count($x[0]); $i++) {
29201:            $xref[] = [intval($x[1][$i]), $x[2][$i], $x[3][$i]];

This is mPDF and PHP version and environment (fpm/cli etc) I am using
mPDF 7.0.0
PHP 5.6.31 (also tried PHP 7.0.23 & PHP 7.1.9)
Apache 2.4.27
Symfony 3.2.13
(WAMPSERVER 3.1.0 - 64-bit)
This is a PHP code snippet I use
    /**
     * @Route("/test/", name="test")
     */
    public function testAction(Request $request)
    {
        $mpdf = new \Mpdf\Mpdf();
	$mpdf->SetImportUse();

	$mpdf->percentSubset = 0;

	$search = array(
		'{{test1}}',
		'{{test2}}'
	);

	$replacement = array(
		"THIS IS A TEST",
		"THIS IS ANOTHER TEST"
	);

	if (!file_exists('../test.pdf')) die("FILE DOES NOT EXIST");
		
	$mpdf->OverWrite('../test.pdf', $search, $replacement, 'D', 'report.pdf' ) ;
     }

Duplicate issue #268: OverWrite not replacing text
Created: 2016-11-18T16:37:49Z
I have this problem/would like to have this functionality
I want to replace text inside a PDF document (the basics), it now shows the original PDF without replacements.
These are mPDF and PHP versions I am using
PHP 7.0.2 and mPDF 6.1.0
This is a PHP code snippet I use
<?php
//Replace these to your file locations
$inputFileName = \Yii::getAlias('@app/tmp/pdf/tmp/imation.pdf');
$outputFileName = \Yii::getAlias('@app/tmp/pdf/tmp/imation2.pdf');

//Replace contents
$mPDF = new \mPDF();
$mPDF->SetImportUse();
$mPDF->percentSubset = 0;
$mPDF->OverWrite( $inputFileName, 'naam', 'Martijn', 'F', $outputFileName ) ;


imation.pdf

Closing comment (2018-05-12T07:46:24Z): Duplicate of #626