829435 - Japanese characters appear completely garbled in PDF viewer

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Alice0775 White]

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/0a6e5a67c4e8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130110 Firefox/21.0 ID:20130110030939

COMPLETELY BROKEN in Firefox.

The problem does not happen in Google Chrome 23.0.1271.97 m.

Steps to reproduce:
1. Open Firefox with newly created profile
2. Open attached pdf

Actual results:
The characters were garbled.

Expected results:
Should be rendered with proper characters

Comment 1

[Alice0775 White]

Attachment: sample pdf

Comment 2

[Alice0775 White]

Attachment: Screen shot, comparison between Firefox and Google Chrome

Comment 3

[Alice0775 White]

The problem happen in Firefox 19 and later.
http://hg.mozilla.org/releases/mozilla-beta/rev/222e6877be4b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 ID:20130109111322

However, The Problem does not happen in Firefox18
http://hg.mozilla.org/releases/mozilla-release/rev/8efe34fa2289
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 ID:20130104151925

Comment 4

[Masatoshi Kimura [:emk]]

I saw this bug even on Firefox 18 if I installed pdf.js add-on.
I reported this bug from way back, but it is abandoned.
https://github.com/mozilla/pdf.js/issues/696
Although I personally agree we should not ship pdf.js without fixing this bug, it looks like they are not interested in fixing the problem specific to Japanese.

Comment 5

[Alice0775 White]

(In reply to Alice0775 White from comment #3)
> The problem happen in Firefox 19 and later.
> http://hg.mozilla.org/releases/mozilla-beta/rev/222e6877be4b
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
> ID:20130109111322
> 
> However, The Problem does not happen in Firefox18
> http://hg.mozilla.org/releases/mozilla-release/rev/8efe34fa2289
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
> ID:20130104151925

Comment 6

[Masatoshi Kimura [:emk]]

(In reply to Alice0775 White from comment #5)
> (In reply to Alice0775 White from comment #3)
> > The problem happen in Firefox 19 and later.
> > http://hg.mozilla.org/releases/mozilla-beta/rev/222e6877be4b
> > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
> > ID:20130109111322
> > 
> > However, The Problem does not happen in Firefox18
> > http://hg.mozilla.org/releases/mozilla-release/rev/8efe34fa2289
> > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
> > ID:20130104151925

It's just because PDF viewer is not enabled on Firefox 18, no?

Comment 7

[Masatoshi Kimura [:emk]]

I bet this bug will not be fixed unless someone in Japan write a patch and send a pull-request.

Comment 8

[Alice0775 White]

(In reply to Masatoshi Kimura [:emk] from comment #4)
> I saw this bug even on Firefox 18 if I installed pdf.js add-on.
> I reported this bug from way back, but it is abandoned.
> https://github.com/mozilla/pdf.js/issues/696
> Although I personally agree we should not ship pdf.js without fixing this
> bug,

> it looks like they are not interested in fixing the problem specific to
> Japanese.

OK, in this case,I requested, Disable PDF.js In FF19 Beta  and forever.

Comment 9

[Masatoshi Kimura [:emk]]

I set "pdfjs.disabled" to false and tried to view the PDF with Firefox 18 internal viewer, but it was not displayed at all with the following error: "TypeError: currentPage is undefined @ resource://pdf.js/web/viewer.js:361".
You must have used something other than internal PDF viewer on Firefox 18.

Comment 10

[Masatoshi Kimura [:emk]]

(In reply to Alice0775 White from comment #8)
> OK, in this case,I requested, Disable PDF.js In FF19 Beta  and forever.

It should be disabled on release and beta unless this bug is fixed, but there is no reason to disable it on other channels. You can easily select other viewers from Options > Applications > Portable Document Format (PDF).

Comment 11

[Alice0775 White]

(In reply to Masatoshi Kimura [:emk] from comment #9)
> I set "pdfjs.disabled" to false and tried to view the PDF with Firefox 18
> internal viewer, but it was not displayed at all with the following error:
> "TypeError: currentPage is undefined @ resource://pdf.js/web/viewer.js:361".
> You must have used something other than internal PDF viewer on Firefox 18.

My bad.
Yes, you are correct.
Firefox18 is disabled PDFjs by default.

Comment 12

[Alice0775 White]

(In reply to Masatoshi Kimura [:emk] from comment #10)
> (In reply to Alice0775 White from comment #8)
> > OK, in this case,I requested, Disable PDF.js In FF19 Beta  and forever.
> 
> It should be disabled on release and beta unless this bug is fixed, but
> there is no reason to disable it on other channels. You can easily select
> other viewers from Options > Applications > Portable Document Format (PDF).

OK,

Comment 13

[Masatoshi Kimura [:emk]]

Nominating this for a release blocker.

Comment 14

[Marco Castelluccio [:marco]]

PDF.js is in the release notes of Firefox 19: http://www.mozilla.org/en-US/firefox/19.0beta/releasenotes/

Comment 15

[Masatoshi Kimura [:emk]]

It was also written in the release notes of Firefox 18, but eventually disabled.

Comment 16

[Masatoshi Kimura [:emk]]

Attachment: Disable pdf.js on release and beta channels automatically

Using RELEASE_BUILD build-time flag introduced by bug 820148.

Comment 17

[Yury Delendik (:yury)]

Is this issue appearing on all Japanese PDF documents? If not, what portion of the documents looks bad vs looks good?

Comment 18

[Masatoshi Kimura [:emk]]

Not all PDFs, but many are. In particular, many Japanese mathematical papers are generated by a tool which encodes the text with Shift_JIS.

This is just a small example:
http://www.kurims.kyoto-u.ac.jp/~terui/mita05.pdf
http://phsc.jp/dat/rsm/2009061303.pdf
http://hagi.is.s.u-tokyo.ac.jp/pub/staff/hagiya/kougiroku/ronri/5.pdf
http://www.math.tohoku.ac.jp/~y-keita/papers/summer-school2010-print.pdf
http://www.cc.kyoto-su.ac.jp/~yasugi/page/Kakenhi/intro06.pdf
http://www.seto.nanzan-u.ac.jp/msie/gr-thesis/ms/2007/04mm088.pdf
http://www.seitoku.ac.jp/~ikedak/y-ss06.pdf
http://www.math.tohoku.ac.jp/~y-keita/old/090509TIT.pdf
http://staff.aist.go.jp/shunsuke.yatabe/Onishi090516.pdf
http://www7.plala.or.jp/isaragi/set/pdf/1.pdf
http://ac-net.org/tjst/doc/lect/am99/3am99.pdf

Comment 19

[Masatoshi Kimura [:emk]]

A example of non-mathematical paper:
http://jp.xlsoft.com/documents/windriver/wdman10J.pdf

Comment 20

[Pomax]

You can use different PDF viewers with Firefox instead of using PDF.js, and PDF.js works with a large proportion of PDFs found in the wild, so this is a case of a missing support feature in PDF.js, rather than something that makes it impossible to view certain things on the web anymore. Asking for its removal or even suggesting blocking a release on a missing feature in an optional library is going a little far =)

Constructively speaking, if PDF.js is having problems with a subset of PDF files such as files that use SHIFT_JIS encoding (used in many older Japanese PDFs, before Unicode become more popular) then it's a good idea to file a bug on this over at the PDF.js github tracker (http://github.com/mozilla/pdf.js/issues) so that it can be fixed, along the lines of "pdf.js does not support PDF files with SHIFT_JIS encoded text". This'll let the PDF.js dev team make sure the issue gets tracked by the people who work on the code, including non-mozilla volunteers who contribute to its codebase (they only look at the github issues, not mozilla's bugzilla)

Comment 21

[Masatoshi Kimura [:emk]]

(In reply to Mike "Pomax" Kamermans from comment #20)
> Constructively speaking, if PDF.js is having problems with a subset of PDF
> files such as files that use SHIFT_JIS encoding (used in many older Japanese
> PDFs, before Unicode become more popular) then it's a good idea to file a
> bug on this over at the PDF.js github tracker
> (http://github.com/mozilla/pdf.js/issues) so that it can be fixed, along the
> lines of "pdf.js does not support PDF files with SHIFT_JIS encoded text".
> This'll let the PDF.js dev team make sure the issue gets tracked by the
> people who work on the code, including non-mozilla volunteers who contribute
> to its codebase (they only look at the github issues, not mozilla's bugzilla)

Could you please read comment #4?

Comment 22

[Masatoshi Kimura [:emk]]

(In reply to Mike "Pomax" Kamermans from comment #20)
> You can use different PDF viewers with Firefox instead of using PDF.js,

I know (see comment #10), but many novice users would have never even seen the Options dialog. Even the bug reporter, a very experienced user, didn't know.

> and
> PDF.js works with a large proportion of PDFs found in the wild, so this is a
> case of a missing support feature in PDF.js, rather than something that
> makes it impossible to view certain things on the web anymore. Asking for
> its removal or even suggesting blocking a release on a missing feature in an
> optional library is going a little far =)

I didn't propose removing the PDF viewer. You can use PDF viewer by flipping "pdfjs.disabled", as you probably know :)

Comment 23

[Yury Delendik (:yury)]

Masatoshi, I'm not sure why "The characters were garbled in PDF viewer" issue was escalated to "Disable PDF.js In FF19 Beta". As far as I understand, it shall just stay as "The characters were garbled in PDF viewer" and be a blocker to ff19 release bug.

Comment 24

[Masatoshi Kimura [:emk]]

(In reply to Yury (:yury) from comment #23)
> Masatoshi, I'm not sure why "The characters were garbled in PDF viewer"
> issue was escalated to "Disable PDF.js In FF19 Beta". As far as I
> understand, it shall just stay as "The characters were garbled in PDF
> viewer" and be a blocker to ff19 release bug.

The reporter changed the title, not me.

Comment 25

[Alice0775 White]

(In reply to Yury (:yury) from comment #23)
> Masatoshi, I'm not sure why "The characters were garbled in PDF viewer"
> issue was escalated to "Disable PDF.js In FF19 Beta". As far as I
> understand, it shall just stay as "The characters were garbled in PDF
> viewer" and be a blocker to ff19 release bug.

I thought that PSDjs is not reached the level of beta release and also aurora.

Comment 26

[Yury Delendik (:yury)]

(In reply to Masatoshi Kimura [:emk] from comment #24)
> (In reply to Yury (:yury) from comment #23)
> > Masatoshi, I'm not sure why "The characters were garbled in PDF viewer"
> > issue was escalated to "Disable PDF.js In FF19 Beta". As far as I
> > understand, it shall just stay as "The characters were garbled in PDF
> > viewer" and be a blocker to ff19 release bug.
> 
> The reporter changed the title, not me.

The patch was submitted by you, so I thought you have some information that makes this patch the only solution for the issue.

(In reply to Alice0775 White from comment #25)
> I thought that PSDjs is not reached the level of beta release and also
> aurora.

What criteria was used to determine that PDF.js is not reached the level of beta or aurora release?

Comment 27

[Bill Walker [:bwalker] [@wfwalker]]

(In reply to Yury (:yury) from comment #26)
> (In reply to Masatoshi Kimura [:emk] from comment #24)
> > (In reply to Yury (:yury) from comment #23)
> > > Masatoshi, I'm not sure why "The characters were garbled in PDF viewer"
> > > issue was escalated to "Disable PDF.js In FF19 Beta". As far as I
> > > understand, it shall just stay as "The characters were garbled in PDF
> > > viewer" and be a blocker to ff19 release bug.
> > 
> > The reporter changed the title, not me.
> 
> The patch was submitted by you, so I thought you have some information that
> makes this patch the only solution for the issue.
> 
> (In reply to Alice0775 White from comment #25)
> > I thought that PSDjs is not reached the level of beta release and also
> > aurora.
> 
> What criteria was used to determine that PDF.js is not reached the level of
> beta or aurora release?

Hello,

The PDF.js team has been working hard the last six months to address rendering bugs based on their severity and breadth of impact. It is very unfortunate that some Japanese language documents won't render properly, but in my opinion this symptom in no way justifies disabling the PDF viewer in FF19.

I propose that we discuss this bug in our regularly scheduled bug triage meeting on Monday, January 14th. Details will be published in dev-pdf-js mailing list, please join us! Until then, I'd like to revert this bug back to a description of its symptom, which is how we can make best use of Bugzilla.

Comment 28

[Masatoshi Kimura [:emk]]

Actually there were two different reasons for the garbled text. Filed https://github.com/mozilla/pdf.js/issues/2559 for the second.

Comment 29

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Comment on attachment 701004 [details] [diff] [review]
Disable pdf.js on release and beta channels automatically

While technically I could review this patch, I can't take such a decision, that's up to the module owner and release management.

I wonder if there's no "safe" fix that could be taken in Beta to address this problem?

Comment 30

[Masatoshi Kimura [:emk]]

I'm sending a pull request to upstream.
https://github.com/mozilla/pdf.js/pull/2561
This patch will fix only the second problem.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 701004 [details] [diff] [review]
Disable pdf.js on release and beta channels automatically

This seems premature. Let's try to address this problem before disabling pdf.js wholesale.

Comment 32

[Alex Keybl [:akeybl]]

One option may be to automatically disable PDF.js for Japanese locale builds, if we can't find a low risk fix in time for FF19. Users on other localized builds can always choose to open the PDF in an external reader.

Comment 33

[Masatoshi Kimura [:emk]]

The reported attachment is still garbled. That is
https://github.com/mozilla/pdf.js/issues/696
. The PDF uses '90ms' encoding.

Comment 34

[Masatoshi Kimura [:emk]]

Still garbled PDFs from comment #18:
http://www.math.tohoku.ac.jp/~y-keita/papers/summer-school2010-print.pdf
http://www.math.tohoku.ac.jp/~y-keita/old/090509TIT.pdf
http://www7.plala.or.jp/isaragi/set/pdf/1.pdf
Their CMap is "H" (JIS 7-bit).

Comment 35

[Masatoshi Kimura [:emk]]

Attachment: Support some CMap encodings without embedded fonts

[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A
User impact if declined: Some PDFs are not readable for Japanese users.
Testing completed (on m-c, etc.): upstream
Risk to taking this patch (and alternatives if risky): Medium. An obvious alternative is disabling PDF viewer (at least on Japanese localization).
String or UUID changes made by this patch: None

Comment 36

[Lukas Blakk [:lsblakk] use ?needinfo]

Adding qawanted to get some testing around this fix so we can confirm whether it is lower risk to disable pdf.js on jp builds or land this to branches.  Can qa confirm if this patch makes the feature usable on jp builds?

Comment 37

[Alex Keybl [:akeybl]]

(In reply to Masatoshi Kimura [:emk] from comment #35)
> Risk to taking this patch (and alternatives if risky): Medium. An obvious
> alternative is disabling PDF viewer (at least on Japanese localization).

Out of curiosity, is this medium risk evaluation for PDFs with Japanese characters, or for all PDFs? How do you expect a regression to manifest itself?

Comment 38

[Masatoshi Kimura [:emk]]

(In reply to Lukas Blakk [:lsblakk] from comment #36)
> Adding qawanted to get some testing around this fix so we can confirm
> whether it is lower risk to disable pdf.js on jp builds or land this to
> branches.  Can qa confirm if this patch makes the feature usable on jp
> builds?

Can qa read Japanese and determine that the characters are garbled?

(In reply to Alex Keybl [:akeybl] from comment #37)
> Out of curiosity, is this medium risk evaluation for PDFs with Japanese
> characters, or for all PDFs? How do you expect a regression to manifest
> itself?

Some other PDFs' display may be regress (but I don't encounter that for now). Non-CJK PDFs are less likely to regress because patched parts are involving multibyte character encodings.

Comment 39

[rshimazu]

The following PDFs are examples of PDFs, which pdf.js can not render as we expect.

http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/JST2007-5.pdf
http://www.jsce.or.jp/committee/amc/jam/DOC/jam_makepdf.pdf
http://www.nii.ac.jp/userdata/shimin/documents/H23/111005_4thlec02.pdf
http://www.cyflex.jp/knowhow/f_know/f_mojibake.pdf
http://asciimw.jp/info/release/pdf/20080908b.pdf
http://www.kyotanabe.ed.jp/jouhou_k/pdf/firefox.pdf
http://www.unisys.co.jp/tec_info/tr93/9306.pdf
http://www.jasst.jp/archives/jasst07k/pdf/T1.pdf
http://www.cqpub.co.jp/dwm/contents/0110/dwm011000820.pdf
http://www.jasst.jp/archives/jasst05w/pdf/S4-1.pdf
http://www.marubun-arita.co.jp/to/rabachi/rabachi.pdf
http://www.jst.go.jp/kisoken/crest/research_area/ongoing/21senryaku_1.pdf
http://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/57579/1/takahashi1.pdf
http://www.alpha-web.jp/service/internet/roaming/pdf/wlan-ap04.pdf
http://www.yaf.or.jp/mmh/recommend/McSeat.pdf
http://www.kanebo-cosmetics.co.jp/company/pdf/20120926-02.pdf

The followings are also examples which pdf.js can not render as expected.
They may look fine to you, but they seem Chinese sentences to us Japanese.

http://www.ztv.co.jp/support/column/2008/pdf/giju_column051.pdf
http://wl.emit-japan.com/past/tips/pdf/tips_character_change.pdf
http://www.jkn.auecc.aichi-edu.ac.jp/for_user/tip/firefox/firefox.pdf
http://www.mew.org/~kazu/material/2008-malloc.pdf
http://www.mext.go.jp/a_menu/sports/stamina/05030101/001.pdf
http://www.apu.ac.jp/~makita/pdf/2.pdf
http://www.isc.meiji.ac.jp/~pkchoi/gelpaper.pdf

http://azusa.shinshu-u.ac.jp/~haru/miracle.pdf

As far as I investigate very briefly, 1 out of 8 or 12 Japanese PDFs on the WEB seem to have problems with pdf.js. I searched PDFs with the keyword "filetype:pdf arbitary-keywords" in Yahoo or in Google.

I wish you disable pdf.js by default in Firefox 19 Japanese version unless this bug is fixed.

Comment 40

[Masatoshi Kimura [:emk]]

All the above examples are rendered without garbled text using with patched pdf.js 0.7.82.

Comment 41

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Lukas Blakk [:lsblakk] from comment #36)
> Adding qawanted to get some testing around this fix so we can confirm
> whether it is lower risk to disable pdf.js on jp builds or land this to
> branches.  Can qa confirm if this patch makes the feature usable on jp
> builds?

Is there any build with this fix?

Comment 42

[Masatoshi Kimura [:emk]]

(In reply to Mihaela Velimiroviciu [QA] (:mihaela) from comment #41)
> (In reply to Lukas Blakk [:lsblakk] from comment #36)
> > Adding qawanted to get some testing around this fix so we can confirm
> > whether it is lower risk to disable pdf.js on jp builds or land this to
> > branches.  Can qa confirm if this patch makes the feature usable on jp
> > builds?
> 
> Is there any build with this fix?

Made tryserver builds.
aurora: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-47ea74f63363/
beta: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-83dec4f3c354/

Comment 43

[Yury Delendik (:yury)]

Fix for m-c will land in bug 832995

Comment 44

[Mihaela Velimiroviciu (:mihaelav)]

(Tested on Win 7 x86 and Ubuntu 12.10 x86, both beta and aurora try builds)

The Japanese characters painting issue seems to be solved with this fix. There are still a few issues, though:
1. Non-Japanese characters spacing is incorrect in most documents. See for example: 
  - http://www.unisys.co.jp/tec_info/tr93/9306.pdf
  - http://www.cqpub.co.jp/dwm/contents/0110/dwm011000820.pdf
  - http://asciimw.jp/info/release/pdf/20080908b.pdf
2. Sometimes non-Japanese chars are displayed incorrect or not displayed at all
  - http://www.nii.ac.jp/userdata/shimin/documents/H23/111005_4thlec02.pdf - numbers not displayed correctly (other characters painted instead numbers)
  - http://www.alpha-web.jp/service/internet/roaming/pdf/wlan-ap04.pdf - missing "alpha" character
3. 「 and 」 not correctly displayed in most of pdfs (the vertical lines are too short). This seem to happen only on Ubuntu
4. Where writing is vertical with Japanese characters, it is displayed horizontally; see page 3 in http://www.jasst.jp/archives/jasst05w/pdf/S4-1.pdf 

There are some documents in which Japanese characters are still not displayed correctly - see chapter names and spacing in http://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/57579/1/takahashi1.pdf

For most documents that are not displayed correctly, the "The PDF document might not be displayed correctly" message pops up (on Windows).

Comment 45

[Masatoshi Kimura [:emk]]

(In reply to Mihaela Velimiroviciu [QA] (:mihaela) from comment #44)
> (Tested on Win 7 x86 and Ubuntu 12.10 x86, both beta and aurora try builds)
> 
> The Japanese characters painting issue seems to be solved with this fix.
> There are still a few issues, though:
> 1. Non-Japanese characters spacing is incorrect in most documents. See for
> example: 
>   - http://www.unisys.co.jp/tec_info/tr93/9306.pdf
>   - http://www.cqpub.co.jp/dwm/contents/0110/dwm011000820.pdf
>   - http://asciimw.jp/info/release/pdf/20080908b.pdf
> 2. Sometimes non-Japanese chars are displayed incorrect or not displayed at
> all
>   - http://www.nii.ac.jp/userdata/shimin/documents/H23/111005_4thlec02.pdf -
> numbers not displayed correctly (other characters painted instead numbers)
>   - http://www.alpha-web.jp/service/internet/roaming/pdf/wlan-ap04.pdf -
> missing "alpha" character
> 3. 「 and 」 not correctly displayed in most of pdfs (the vertical lines are
> too short). This seem to happen only on Ubuntu
> 4. Where writing is vertical with Japanese characters, it is displayed
> horizontally; see page 3 in
> http://www.jasst.jp/archives/jasst05w/pdf/S4-1.pdf 
> 
> There are some documents in which Japanese characters are still not
> displayed correctly - see chapter names and spacing in
> http://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/57579/1/
> takahashi1.pdf
> 
> For most documents that are not displayed correctly, the "The PDF document
> might not be displayed correctly" message pops up (on Windows).

Yeah, but
- Those problems are not regressions (not caused by this patch).
- Those problems are out of scope of this bug.
- It's much better than completely unreadable text.

Comment 46

[Alex Keybl [:akeybl]]

Comment on attachment 703068 [details] [diff] [review]
Support some CMap encodings without embedded fonts

Given the fact that none of the issues found are thought to be regressions, let's land now and ensure that this fix gets into beta 3 of FF19.

Comment 47

[Masatoshi Kimura [:emk]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d426b31dcadb
https://hg.mozilla.org/releases/mozilla-beta/rev/87fec2d6137d

Comment 48

[Ryan VanderMeulen [:RyanVM]]

pdf.js 0.7.82 update:
https://hg.mozilla.org/mozilla-central/rev/5fae1032ef3b

Comment 49

[Mihaela Velimiroviciu (:mihaelav)]

Verified on Firefox 19 beta 3 (Ubuntu 12.10, Win 7 32bit and Mac 10.8.2): Japanese characters are displayed correctly.

Comment 50

[Atsushi Okawa]

Some(not all) characters in this PDF aren't displayed corrently.

http://navi.hamabus.jp/dia/bustime/pdfdata/510_7813_14.pdf

Comment 51

[Manuela Muntean [Away]]

Verified with Firefox 20 beta 1.

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130220104816

Comment 52

[Mihaela Velimiroviciu (:mihaelav)]

Verified on latest Aurora 21 version: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130305 Firefox/21.0