Date: Tue, 26 Mar 2024 22:28:07 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: masa@amogha.jp Cc: freebsd-users-jp@freebsd.org Subject: Re: =?UTF-8?B?56K65a6a55Sz5ZGK?= Message-ID: <20240326222807.f1e8b3c4da29e22841bf9f7e@dec.sakura.ne.jp> In-Reply-To: <ydlsf0dmws6.fsf@pc06.mar> References: <20240325184500.1062d7f6d14d71ca0d1c7e43@dec.sakura.ne.jp> <ydlsf0dmws6.fsf@pc06.mar>
next in thread | previous in thread | raw e-mail | index | archive | help
青木@名古屋です。 私のところでもFirefoxでは正常に表示できていて、 新たにmupdfをバックエンドとして使用するprint/sioyekを入れてみて 試したところ、これも正常に表示できました。 丸山さんのmupdfの 結果と同様です。 LibreOfficeは前回の投稿のとおりのエラーを吐いて受け付けません。 拡張機能を入れれば解決するかもしれませんが、原因の切り分けが できていないものの、素のchromiumで見ようとすると異常に時間が かかる上に文字がほぼ表示されず（実際は拡大しても判読不能なほど 小さい文字かつ異常なレイアウトで表示されていそう）、東京防災の サイトに行ってPDFを表示しようとすると異常に遅いものの表示は 正常なようでした。 UEFIのサイトで英文の規格を表示しようと しても東京防災と同じ症状でFirefoxと比べて異常に遅いものの 表示自体は正常でした。 それ以外で私が試した範囲では、どれもpopplerをバックエンドとして 使用しています。 丸山さんがテストされたepdfvierもFreshPortsで 見る限りバックエンドは popplerのようです。 私自身はxpdfは試していないものの、丸山さんのテスト結果で駄目 だったとのことですが、[1]を見るとpoppler自体がxpdf由来のよう なので恐らくpopplerがいじっていないxpdf由来の部分に原因が あると考えるのが自然と思われます。 Chromiumの症状も勘案すると、埋込みフォント関連の問題のような 気配がします。 LibreOfficeではそもそも異常として拒否し、 Firefoxやmupdfではおかしいところを無視してデフォルトの フォントに自動で置き換え、Chromiumでは異常なところに引っ張られて 文字のレンダリング全体がおかしくなり、poppler（や、そのベースの xpdf）ではデフォルトフォントに置き換えてなんとかしようとするものの 部分的にうまくいっていないと考えれば辻褄が合いそうです。 いずれにせよPDF自体AdobeがAcrobat用に開発したフォーマットが 後から規格化されたもののため、Android上でしか試せていませんが Acrobat（Adobe Reader）で正常に表示されてしまうとPDF自体の 異常はどこにも文句を言えなくなってしまう（互換性不足! 問題 なし!! 以上!!!と言われても反論不能。 ISO/IECの規格に整合して いなくても、それは規格の方に問題があるとされてしまう）ので、 graphics/popplerについて報告することになりそうですね。 [1] https://ja.wikipedia.org/wiki/Poppler On Tue, 26 Mar 2024 13:39:37 +0900 丸山直昌 <masa@amogha.jp> wrote: > 丸山です。 > > >PDF自体が異常なようです。 > > ありゃー、そういうことですか。お調べくださり、有難うございました。 > > NHKも国税庁も許せん！ > > こうなるとバグレポートをどこに出すか、という話ではないでしょうね。国税庁 > のウェブがよろしくねいPDF を吐くよ、という事実をどうやって明確な証拠付き > で世間に示すか、という方向で考えなくてはいけないでしょう。「Libre Office > がエラーを指摘している」では国税庁を説得できないでしょう。「Acrobatがエ > ラーを指摘している」ならずっと説得力があるでしょうね。 > > 何かそういう説得力がある証拠を出せないでしょうか。 > > (以下引用のみ) > Mon, 25 Mar 2024 18:45:00 +0900 > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> writes: > > >On Mon, 25 Mar 2024 05:32:05 +0900 > >丸山直昌 <masa@amogha.jp> wrote: > > > >> 丸山です。 > >> > >> このMLにも、ブログの方でも何件か反応を頂いております。それで問題点をより > >> 明確にするために、私の個人情報を含まないサンプルファイルを作り、皆様にご > >> 確認頂けるようにしたした。私のブログ > >> > >> 2024年春確定申告作業 > >> https://amogha.livedoor.blog/archives/23827087.html > >> > >> からダウンロードできます。 > >> > >> 13.2の okular, epdfview, xpdf で「ゴミ」が表示に混じります。ただし、 xpdfでは、 > >> okular, epdfview とは違う場所に出ます。 firefox と mupdf では出ません。 > > > >確かにFirefoxでページ閲覧した流れでそのままfirefoxで表示すると > >正常に見えますが、 > > > > ・atril-1.28.0 > > ・okular-23.08.5_3 > > > >では表示がおかしく、libreoffice-24.2.1.2で開こうとすると > > > > Version Incompatibility. > > Incorrect file version. > > > >のエラーダイアログが表示されて開けません。 > >PDF自体が異常なようです。 なお、プライベートな資料をスキャンした > >PDFや過去にダウンロードしていた古いUEFI仕様書（英文＋画像）や > >やはり過去にダウンロードしていた東京防災のPDF（日本語）は正常に > >開けます。 > > > >私の環境では、他で正常という話のあったokular-23.08.5_3でも異常が > >発生することから、特定のフォントがインストールされている（逆に > >特定のフォントがインストールされていない）とフォントのマッピングが > >おかしくなってpopplerを使用しているビューアで異常が発生すると > >いう可能性もありますが、それでは丸山さんの新旧環境での挙動の > >違いが説明できません。 > > > >とりあえず、こちらですぐできる範囲での再現テスト結果です。 > > > >> で、このバグレポートですが、やはり bugzilla に出すのが良いでしょうかね。 > > > >通常ならそうですが、どのportsに対して出すべきかが絞りきれて > >いない（私の再現結果のせいでもありますが）状況では、freebsd-ports > >MLに報告して意見を貰うほうがいいかもしれません。（Bugzilla同様、 > >英文前提ですが。） > > > >> > >> -------- > >> 丸山 直昌 まるやま なおまさ > >> メールアドレス： masa@amogha.jp > -- 青木 知明 [Tomoaki AOKI] <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240326222807.f1e8b3c4da29e22841bf9f7e>