Text-align: justify renders poorly

[GoogleCodeExporter]

This should be an easy fix. When dompdf justifies text, it keeps a space
character at the end of each line. This space prevents the rendering engine
from justifying the text properly. The right edge of the justified text
does not line up and appears grooved.

Original issue reported on code.google.com by dimas.yu...@gmail.com on 22 May 2009 at 9:38

[GoogleCodeExporter]

Original comment by eclecticgeek on 2 Jun 2009 at 4:01

• Changed state: Accepted
• Added labels: Milestone-Release0.5.2

[GoogleCodeExporter]

Original comment by eclecticgeek on 31 Jul 2009 at 3:40

• Added labels: Milestone-Release0.6

[GoogleCodeExporter]

Concordo logo o a justificação que é tão importante nos documentos.

Original comment by alex.qu...@gmail.com on 13 Aug 2009 at 11:34

[GoogleCodeExporter]

I've been using text-align:justify; with no results. Anyone found a solution?

Original comment by xjpmauri...@gmail.com on 10 Oct 2009 at 3:56

[GoogleCodeExporter]

I have used this alongside "white-space: nowrap;" but only if you want to 
achieve the
following:

1) prevent line wrapping
2) condense the text to fit into a small space

If I leave out nowrap it causes problems.

Original comment by read...@gmail.com on 11 Oct 2009 at 12:55

[GoogleCodeExporter]

I've tried "white-space: nowrap;" but the text get's all mixed up. I can't even 
explain it. Does anyone knows if there is anything still to be released that 
adresses this problem? i have dozens of documents already done with dompdf, the 
problem only appears on the server. On my loca instalation of xampp it works ok.

Getting desperate here... :(

Original comment by xjpmauri...@gmail.com on 12 Oct 2009 at 10:25

[GoogleCodeExporter]

@xjpmauricio:
Justification does not work with Unicode enabled (at least with
own-added/self-designed) fonts). This is more or less a problem of the 
PDF-Standard.
I'll post a more detailed description and a patch to the list once I find time 
to
clean it up...

Original comment by florian....@univ-avignon.fr on 24 Oct 2009 at 7:08

[GoogleCodeExporter]

Seems like we should be able to rtrim() the text to achieve the desired result. 
I'll
need to research where this action would best be utilized.

@xjpmauricio: You might have been running into some problems with character 
width
calculations that have since been addressed. Try the latest nightly release
(http://groups.google.com/group/dompdf/msg/608cf69792d05a82). If you you 
continue to
experience problems post a message to the group so we can better pinpoint your 
problem.

@florian.verdet: Have you made any progress on this point? I'd be interested to 
hear
what you've found. Also, this sounds like an issue that would be better 
addressed in
a separate issue, so open a new one if you have anything to report.

Original comment by eclecticgeek on 29 Dec 2009 at 7:40

[GoogleCodeExporter]

I have very problems :~ no wrap, in loclahost with xamp perfect justify, but 
online
problem words wrap  help maiconr@gmail.com tks

Original comment by maic...@gmail.com on 10 Mar 2010 at 2:47

[GoogleCodeExporter]

eclecticgeek

with your code, please view attach 

Original comment by maic...@gmail.com on 10 Mar 2010 at 3:05

Attachments:

• testando(5).pdf

[GoogleCodeExporter]

hi, solution in
http://luca.priorelli.com/lang/en-us/2009/05/19/dompdf-justification-extended-as
cii-chars/

:)

Original comment by maic...@gmail.com on 10 Mar 2010 at 6:33

[GoogleCodeExporter]

I have an update that fixes problems with standard ASCII characters. I do have a
question, though. What should we do when the space at the end of a line is a
non-breaking space. DOMPDF no longer strips these off so it can make a line of 
text
look like it doesn't justify correctly. How do we feel about stripping 
non-breaking
spaces from the end of a line?

Florian, any more information to share on the problems with Unicode?

Original comment by eclecticgeek on 1 Apr 2010 at 6:58

• Changed state: Started

[GoogleCodeExporter]

I think the best thing to do is to have the same behavior as browsers. I tested 
with 
this code :

<div style="width: 240px; text-align: justify; border: 1px solid #999;">
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
  abcdefghijkl mnopqr   
</div>

and the nbsp are kept when at the end of a line (in Chrome 5.0). They seem to 
be 
expanded like normal spaces though.

Original comment by fabien.menager on 1 Apr 2010 at 7:48

[GoogleCodeExporter]

I believe I have a functional patch for when Unicode is disabled. I still have 
a bit
of cleaning up to do. The encoding on the font metrics for the core fonts were 
not
correct (namely they were not based on the encoding used by default in DOMPDF). 
After
I clean those files up I'll turn my attention to Unicode-enabled fonts, which 
still
appear to be rendering incorrectly.

Original comment by eclecticgeek on 12 Apr 2010 at 7:30

[GoogleCodeExporter]

If you need any help testing this, or I don't know what else, just say the word 
- I've 
spent a fair amount of time fiddling with some Japanese fonts and made decent 
progress 
towards embedding font subsets... One tool that jumped my understanding way 
forward 
was using fontforge to open fonts and then comparing that to what ended up in 
my 
subsets and also into the PDF itself.

Original comment by ryl...@gmail.com on 14 Apr 2010 at 6:02

[GoogleCodeExporter]

Likewise I would be happy to test.  I'm working with some French text that 
exhibits
this problem and I would be glad to test and report if it fixes it.

Original comment by duane.g...@gmail.com on 15 Apr 2010 at 12:29

[GoogleCodeExporter]

I really need this work. I have a whole system just waiting on this final 
thing. Any
news yet on a fix?

Original comment by mick.d...@gmail.com on 21 Apr 2010 at 4:01

[GoogleCodeExporter]

I'm working out some problems with user-installed fonts when Unicode is 
enabled, but
that is the last thing I need to do. Hopefully I can get it figured out this 
week,
but I'm still tracking down the problem.

Original comment by eclecticgeek on 21 Apr 2010 at 4:19

[GoogleCodeExporter]

excellent, anything I can do to help just let me know. I have been looking over 
and
over to try and get this to work. I have unicode disabled, but am still not 
able to
get this working. I have just upgraded to 0.6 beta to try and resolve it on 
here.

Original comment by mick.d...@gmail.com on 21 Apr 2010 at 7:19

[GoogleCodeExporter]

I have yet to commit the modifications I've made. So even if you download the 
current
developer version from the repository you won't see any changes. I think I'm 
getting
closer to understanding the problem.

If I'm not able to make some headway I may commit the current modifications now 
and
try and fix Unicode support later. I would like, however, to post a patch that
addresses the issue fully.

Original comment by eclecticgeek on 21 Apr 2010 at 8:27

[GoogleCodeExporter]

I committed a patch that partially addresses this issue (r257). The patch 
focuses on two areas:
  1) spaces at the beginning and end of non-wrapped text
  2) justify support for Unicode text

Regarding justified Unicode text, the PDF spec does not allow word spacing 
modification to a text string 
using the Tw parameter when the font encoding is multi-byte (reference section 
5.2.2 of the PDF 1.3 spec). 
So I worked around the problem by breaking the text string into individual 
words. The words are rendered 
using the TJ operator instead of Tj (meaning they can be rendered as a group). 
The word spacing modification 
is then manually applied between each set of words (reference section 5.3.2 of 
the PDF 1.3 spec).

Unfortunately, the results aren't quite polished enough to close out this 
issue. Also, I haven't had a chance to 
pull together a solution for dealing with left over spaces on wrapped text. We 
can't just strip these out during 
text reflow because that causes rendering problems.

Original comment by eclecticgeek on 29 Apr 2010 at 2:50

[GoogleCodeExporter]

The solution is here (a php function witch justify like microsoft word)

<?php
define('JPAD_LEFT', 1);     // More spaces are added on the left of the line
define('JPAD_RIGHT', 2);    // More spaces are added on the right of the line
define('JPAD_BOTH', 4);     // Tries to evenly distribute the padding
define('JPAD_AVERAGE', 8);  // Tries to position based on a mix of the three 
algorithms

function justify($input, $width, $mode = JPAD_AVERAGE)
{
    // We want to have n characters wide of text per line. 
    // Use PHP's wordwrap feature to give us a rough estimate.
    $justified = wordwrap($input, $width, "\n", false);
    $justified = explode("\n", $justified);

    // Check each line is the required width. If not, pad
    // it with spaces between words.
    foreach($justified as $line)
    {
        if(strlen($line) != $width)
        {
            // Split by word, then glue together
            $words = explode(' ', $line);
            $diff  = $width - strlen($line);

            while($diff > 0)
            {    
                // Process the word at this diff
                if     ($mode == JPAD_BOTH)  $words[$diff / count($words)] .= ' ';
                else if($mode == JPAD_AVERAGE)  
                    $words[(($diff / count($words)) + 
                            ($diff % count($words)) + 
                            (count($words) - ($diff % count($words)))) 
                            / 3] .= ' ';
                else if($mode == JPAD_LEFT)  $words[$diff % count($words)] .= ' ';
                else if($mode == JPAD_RIGHT) $words[count($words) - ($diff % count($words))] .= ' ';

                // Next diff, please... 
                $diff--;
            }
        }
        else
        {
            $words = explode(' ', $line);
        }

        $final .= implode(' ',  $words) . "\n";
    }

    // Return the final string
    return $final;
}
?>

Original comment by voviz.ot...@gmail.com on 18 Aug 2011 at 1:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by eclecticgeek on 24 May 2013 at 3:00

• Added labels: Restrict-AddIssueComment-Commit