Created attachment 130021 [details] [review] Patch In src/cairo-pdf-operators.c, _word_wrap_stream_write might insert a newline into the output of _cairo_pdf_operators_emit_glyph_string_with_positioning in the middle of an escape sequence and result in a broken PDF (or PS) file. The code responsible for this: if (*data == '\n' || stream->column >= stream->max_column) { _cairo_output_stream_printf (stream->output, "\n"); stream->column = 0; } else if (*data == '<') { stream->state = WRAP_STATE_HEXSTRING; } else if (*data == '(') { stream->state = WRAP_STATE_STRING; } else if (!_cairo_isspace (*data)) { stream->state = WRAP_STATE_WORD; } When the "stream->column >= stream->max_column" case is hit, stream->state doesn't get updated. Here's a (simplified, purged of private information) example of how this can be a problem: [......................................................................27 (<)................................................................-713(\ ()...]TJ After "27(", the state didn't get changed to WRAP_STATE_STRING, so it got incorrectly set to WRAP_STATE_HEXSTRING after the "<". The rest of the sequence was wrapped with hex-string rules, and a newline was put in "-713(\()" exactly where it shouldn't be.
https://cgit.freedesktop.org/cairo/commit/?id=1a307123af14cfa50a0c35819cfaee79f0ade1ba
Since the original example is quite long, I would like to add a short example extracted from a real programming document that hits this bug hard. The example is the following short LaTeX document whose PDF is produced using `pdflatex' that comes with Ubuntu 16.04 (pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian)): -- 8< -- mwe.tex ---- \documentclass{article} \usepackage[T1]{fontenc} \usepackage{libertine} \usepackage{listings} \begin{document} \begin{lstlisting} xxxxxxxxxxxx<xxxxxx, !xxx> \end{lstlisting} \end{document} -- 8< -- mwe.tex ---- Opening the resulting PDF using Evince in Ubuntu 16.04 that uses Cairo 1.14.6 and printing it to Kyocera TASKalfa 4551ci result in the following print out: -- 8< --------------- Error Name: /undefined Offending Command: **** Operand Stack: -- 8< --------------- Investigating the PS file that Evince produces when the PDF is printed to a PS file shows the culprit, which is a newline at offset 00004f11, shown below: 00004f10: 2d0a 3135 3728 3e29 5d54 4a0a 3136 2e39 -.157(>)]TJ.16.9 I confirm that commit e2ab1c608fcb54d86ac30852aec4cac36ef1e577, which refers to this bug report, solves the problem.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.