Bug 100029

Summary: Broken pdf/ps output due to badly placed newline
Product: cairo Reporter: jmmorlan
Component: pdf backendAssignee: Adrian Johnson <ajohnson>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Patch

Description jmmorlan 2017-03-02 02:51:08 UTC 
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.
Comment 2 Tadeus Prastowo 2019-03-03 11:11:08 UTC 
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.