Pdf.js: Формулы нарисованы слишком крупно.

Я забыл упомянуть: я использую PDF Viewer 0.7.1 с Firefox 18.0.1 в Ubuntu Linux.

Похоже, это влияет только на linux

Однако Windows также отображает ошибку в журнале:
[16: 59: 53.199] Ошибка при синтаксическом анализе значения «размер шрифта». Декларация отброшена. @ http://arxiv.org/pdf/0707.3195v1.pdf
[16: 59: 53.569] Ошибка при синтаксическом анализе значения для "шрифта". Декларация отброшена. @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh , как вы думаете, это связано?

@yurydelendik :

@yurydelendik Я думаю, мы можем закрыть это. Я не могу воспроизвести проблему при разработке Arch Linux x64, Firefox 22 и pdf.js. Также никаких проблем на Windows 7 x64.

Я просто дважды проверил. Проблема все еще сохраняется на моих машинах.
(оба Ubuntu Linux 12.04, Firefox 22, Pdf.js 0.8.1)

Возможно, это исправлено в разработке pdf.js, хотя я не знаю.

Дайте мне знать, если хотите, чтобы я что-нибудь протестировал.

Возможно, это исправлено в разработке pdf.js, хотя я не знаю.
Дайте мне знать, если хотите, чтобы я что-нибудь протестировал.

@kaymes Попробуйте загрузить файл и открыть его (нажав кнопку «Открыть файл», расположенную справа на панели инструментов PDF.js) в веб-программе просмотра: http://mozilla.github.io/pdf.js /web/viewer.html.
При этом всегда используется последняя версия PDF.js, поэтому попробуйте ее и посмотрите, правильно ли отображается файл.

Я только что попробовал онлайн-просмотрщик на
http://mozilla.github.io/pdf.js/web/viewer.html. Он по-прежнему отображается неправильно
со всеми скобами слишком большими. Это был еще один компьютер
но также один, работающий под Ubuntu 12.04 с Firefox 22. Так что проблема может быть в
Специфично для Linux (или даже для Ubuntu), но он отображается как минимум на трех
разные машины.

Хм, странно. В этом случае, я думаю, это будет специфично для Ubuntu, потому что здесь в Arch Linux нет проблем. Узнавать что-то новое каждый день :-)

Я только что проверил, не виноват ли какой-то аддон. Я запустил firefox
в безопасном режиме и открыл документ с помощью онлайн-просмотра. В
проблема все еще сохраняется. Так что аддоны можно исключить.

И я сделал еще один тест: я загрузил Firefox прямо из Mozilla. Так
все патчи / модификации Ubuntu исчезли. А потом я начал это
в безопасном режиме. Проблема все еще существует.

Я тоже это вижу в Ubuntu 13.04

[18:42:43.639] "PDF 8d10792f8d2028a66825b6ce6ab5b3c1 [1.4 GPL Ghostscript GIT PRERELEASE 9.05 / dvips(k) 5.95a Copyright 2005 Radical Eye Software] (PDF.js: 0.8.510)

Это все еще проблема с последней разработанной версией PDF.js на http://mozilla.github.io/pdf.js/web/viewer.html? Я не могу воспроизвести это в Arch Linux.

Проблема все еще преобладает (Ubuntu 12.04, FF26).

В Linux Mint на базе Ubuntu эта ошибка также воспроизводится в Google Chrome 34 (и Firefox 32.0a1), так что это не исключительная проблема Firefox. Однако Opera 12.16 отображает корректно.

Я просто буду использовать в этом комментарии слова TeX, LaTeX и математику, чтобы люди могли найти эту ошибку.

Похоже, это связано со сглаживанием: я использую gnome 3.14 на машине Debian Jessie, Firefox 33.0.2. Как в сглаживании RGB, так и в оттенках серого, когда выбрана опция Slight hinting (в Gnome Tweak Tool), у меня такая же проблема. Когда я перехожу на любой из других вариантов хинтовки (Полный, Средний или Нет), он выглядит так, как задумано.

Обратите внимание, что в Firefox вам, по крайней мере, нужно обновить вкладку, чтобы увидеть изменения.

Для меня (Arch Linux) эта ошибка появляется, если я использую пропатченный infinality fontconfig / freetype. Использование ванильных пакетов не показывает эту ошибку.

Я не знаю, связано ли это с исправлениями или с конфигурацией, поставляемой с исправленными пакетами.

Может воспроизводиться в Ubuntu 14.04 в Chromium и Firefox. Обратите внимание, как меняются артефакты при масштабировании документа. Я видел эту ошибку в десятках документов pdfTeX в pdf.js, например, также затрагиваются индексы сумм.

Это действительно похоже на проблему восходящего потока, хотя я не уверен, куда ее подавать.

Я перестроил Ubuntu 14.04 freetype / fontconfig без большинства патчей для конкретного дистрибутива, но проблема не исчезла.

Я также установил последнюю версию freetype / fontconfig из Ubuntu 15.10, но проблема не устранена.

Возможно, это нужно зарегистрировать как ошибку восходящего потока Firefox (Linux)? Я просто не уверен, вызвано ли это Firefox или конкретной библиотекой шрифтов Linux.

Вот минимальный тестовый пример:

\documentclass{article}
\begin{document}
$$ \sqrt{\frac{1}{2}} $$
\end{document}

Это по-разному отображается в Ubuntu и Windows:

<style type="text/css">
* { margin:0; padding: 0 }
@font-face { font-family:"g_font_1";src:url(data:font/opentype;base64,T1RUTwAJAIAAAwAQQ0ZGIEG/4oQAAACcAAACWU9TLzJL4jE4AAAC+AAAAGBjbWFwAA0ApQAAA1gAAAAsaGVhZKsnRLAAAAOEAAAANmhoZWEDBvRyAAADvAAAACRobXR4BdwAAAAAA+AAAAAMbWF4cAADUAAAAAPsAAAABm5hbWUiztZPAAAD9AAAAgRwb3N0AAMAAAAABfgAAAAgAQAEBAABAQEOTU5QRUhJK0NNRVgxMAABAQFF+BsA+BwB+B0C+B4D+B8EHgoAH4uLHgoAH4uLDAdzHPRwHAWu+ZgFHQAAAKoPHQAAAAAQHQAAAK8RHQAAABwdAAABYhIABQEBDSAtOkBWZXJzaW9uIDAuMTFTZWUgb3JpZ2luYWwgbm90aWNlTU5QRUhJK0NNRVgxME1OUEVISStDTUVYMTBNZWRpdW0AAAAAAAAAAAADAQEDC62LDhwB9BwAABYOHAPoHABvFhwBYxz3jhUc//8GHP8oHAPqBRz/fRz/MgUc//kc//ccAAAc//4cAAAc//8IHAAAHP/8HAANHP/1HAABHP//CBwARBwAawUcAOcc+88FHAAhHAAAHAADHAAAHAAGHAAaCBwCJhwJHQUcAAIcAAccAAIcAAkcAAAcAAUIHAALHP/4HAAJHP/0Hhz/8BwAABz//Rz/8xz//Rz/8ggOHgoEeW8MCboKuguzkgwMs5IMDYsMDh0AAAAcEwBrAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbAsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLAAAAAAADAiQB9AAFAAACigK7AAAAjAKKArsAAAHfADEBAgAAAAAGAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAqMjEqAAAAcgByAwT0cABkAwQLkAAAAAAAAAAAAa8AAAAAAHIAAwAAAAEAAwABAAAADAAEACAAAAAEAAQAAQAAAHL//wAAAHL///+QAAEAAAAAAAEAAAAAEAAAAAAAXw889QAAA+gAAAAAngt+JwAAAACeC34nAAD0cA//AwQAAAARAAAAAAAAAAAAAQAAAwT0cAAA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAfQAAAPoAAAAAFAAAAMAAAAAABQA9gABAAAAAAAAABAAAAABAAAAAAABAA0AEAABAAAAAAACAAcAHQABAAAAAAADAAgAJAABAAAAAAAEAA0ALAABAAAAAAAFAAwAOQABAAAAAAAGAAAARQABAAAAAAAHAAcARQABAAAAAAAIAAcATAABAAAAAAAJAAcAUwADAAEECQAAACAAWgADAAEECQABABoAegADAAEECQACAA4AlAADAAEECQADABAAogADAAEECQAEABoAsgADAAEECQAFABgAzAADAAEECQAGAAAA5AADAAEECQAHAA4A5AADAAEECQAIAA4A8gADAAEECQAJAA4BAE9yaWdpbmFsIGxpY2VuY2VNTlBFSEkrQ01FWDEwVW5rbm93bnVuaXF1ZUlETU5QRUhJK0NNRVgxMFZlcnNpb24gMC4xMVVua25vd25Vbmtub3duVW5rbm93bgBPAHIAaQBnAGkAbgBhAGwAIABsAGkAYwBlAG4AYwBlAE0ATgBQAEUASABJACsAQwBNAEUAWAAxADAAVQBuAGsAbgBvAHcAbgB1AG4AaQBxAHUAZQBJAEQATQBOAFAARQBIAEkAKwBDAE0ARQBYADEAMABWAGUAcgBzAGkAbwBuACAAMAAuADEAMQBVAG4AawBuAG8AdwBuAFUAbgBrAG4AbwB3AG4AVQBuAGsAbgBvAHcAbgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA);}
td { border: 1px solid #ccc; width: 9px; height: 10px; }
</style>
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse;empty-cells:show">
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>
<div style='font:16px "g_font_1";position:absolute;top:0;left:0'>r</div>

https://bugzilla.mozilla.org/show_bug.cgi?id=1200077

Не забывайте, что Chrome также затронут, поэтому, скорее всего, это не ошибка Firefox.
Снимок экрана: Chrome 44 под (на основе Ubuntu) Linux Mint.

https://bugs.freedesktop.org/show_bug.cgi?id=91829

@jethrogb Спасибо, что

Похоже, ребята из freedesktop пришли к выводу, что это отчасти ошибка pdfjs. Так что, вероятно, здесь еще есть над чем поработать.

А пока есть ли какие-нибудь простые обходные пути, кроме увеличения масштаба, пока ошибка не исчезнет? Я часто использую sharelatex, который, кажется, имеет встроенную программу просмотра pdfjs.

Это ошибка pdf.js. Вкратце, pdf.js создает недопустимые шрифты для этих математических символов. Впоследствии автоинтерфейс шрифтов делает неправильные выводы, что приводит к неправильному отображению.

Таким образом, pdf.js должен исправить способ преобразования шрифтов pdf.

Я столкнулся с этой проблемой с расширением Atom pdf view , как еще одно доказательство того, что это не проблема Firefox. Скриншоты того, как это выглядит в atom , в PDF.js и как должно выглядеть .

Я могу подтвердить, что эта проблема существует в Chrome в Ubuntu 15.10.

Эта ошибка теперь должна быть исправлена ​​с помощью последней установленной библиотеки Freetype (> = 2.6.2).

Нет, настоящая ошибка заключается в преобразовании типа 1 в OpenType файла pdf.js, которое создает недопустимые глифы шрифта, и, как ни странно, это еще не исправлено.

О, я неправильно прочитал ошибку восходящего потока. Извините за неверную информацию.
Кстати, я не обнаружил этой ошибки на обеих моих машинах Debian (Jessie и Stretch).

то же самое и здесь: вообще никаких проблем!
Arch Linux x86_64 и шрифты пропатчены infinality [*], firefox 45.0.2
(то же самое происходит с хромом 50.0.2661.75-1)

[*] cairo-infinality-ultimate 1.14.6-1
fontconfig-infinality-ultimate 2.11.95-4
freetype2-infinality-ultimate 2.6.3-2

Приносим извинения, если это неуместно, но я предлагаю вознаграждение в размере 500 долларов за исправление этой ошибки.

В ShareLaTeX мы используем PDF.js для рендеринга PDF-файла, созданного из пользовательских документов LaTeX, и поэтому наши пользователи, вероятно, сталкиваются с этой ошибкой чаще, чем средний пользователь.

Мне не удалось найти никаких прецедентов или комментариев относительно предложения вознаграждения за ошибку для этого проекта, поэтому я надеюсь, что это нормально. Не стесняйтесь связаться со мной по адресу [email protected]. Если вы предпочитаете, мы можем установить вознаграждение в условном депонировании, используя что-то вроде https://www.bountysource.com/ , или если кто-то еще захочет добавить к вознаграждению.

Кстати: это было исправлено в апстриме в freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829

Это не имеет ничего общего с FreeType, как постоянно говорят и как подробно обсуждается в проблеме FreeType, на которую вы ссылаетесь, в конвертере Type1 в OpenType из pdf.js есть ошибка.

Это не имеет ничего общего с FreeType ... есть ошибка в конвертере Type1 в OpenType pdf.js.

Фактически, это проблема, связанная с FreeType, потому что проблема возникает только в этом движке. Возможно, проблема связана с конвертером pdf.js, и будет полезно понять, почему это происходит. К сожалению, приведенная выше ссылка не дает подробных объяснений. Дополнительный вклад экспертов FreeType ускорит устранение этой ошибки.

Файл шрифта, преобразованный с помощью pdf.js
Исходный файл шрифта, встроенный в PDF

Избранные цитаты из отчета об ошибке FreeType:

У рассматриваемого шрифта есть корень на букве «s».

Шрифт содержит cmap, который отображает позицию r' (not s ', BTW) в глиф с именем .notdef'. Since the auto-hinter accesses a font not by glyph names but by a Unicode mapping (either a real one or a synthesized), it believes that glyph r' присутствует

CMAP шрифтов не должен лгать автохинтеру!

О, это, вероятно, частично виноват и pdf.js, возможно, поддельный cmap создается из pdf.js, а не из исходного шрифта. Кому-то нужно проверить.

Исходный файл cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name радикальныйbigg 'в позиции 0x72. Подмножество файла CMEX10.pfb в отчете об ошибке FireFox также имеет правильное имя глифа.

Предварительное исправление в # 7482. У меня нет ресурсов, чтобы разобраться в этом подробнее, если тестирование не удастся, но это может быть просто. Шрифт в pdf немного странный, так как он имеет символьный шрифт, но также имеет отображение Unicode для некоторых символов. Обычно для символьных шрифтов мы перемещаем все глифы в область частного использования, если есть только отображение идентификатора Unicode.

Я могу воспроизвести # 7482, устраняющий проблему для меня, по крайней мере, на второй странице PDF-файла, ссылка на который есть в первом сообщении.

@brendandahl Отлично, спасибо. Я проверю, исправит ли ваш патч это как можно скорее. Может ли слить? (Похоже, что некоторые тесты не работают?)

Может ли слить? (Похоже, что некоторые тесты не работают?)

Это ожидается с таким патчем. Однако перед звонком нам необходимо изучить различия.

Хороший прогресс! Я провел более обширное тестирование и обнаружил осложнение - исправление работает для вывода, созданного dvips + ghostscript, но не для вывода, созданного pdftex - если я возьму источник для тестового примера выше и скомпилирую его с помощью pdflatex, вывод будет отображаться неправильно .

Прилагается более исчерпывающий тестовый пример, включающий одно из сломанных уравнений из исходного файла 0707.3195v1.pdf.

Первый PDF-файл создается непосредственно pdflatex а затем такой же вывод создается latex->dvips->ps2pdf . Скриншоты представляют собой рендеринг из pdf.js с примененным запросом на перенос - он не решает проблему с выводом pdftex, но исправляет его для преобразования ghostscript.

Предположительно, есть что-то другое в способе встраивания шрифта в вывод с помощью pdftex, из-за чего ошибка все еще возникает?

test-pdftex.pdf - все еще не работает

test-ps2pdf.pdf - исправлено

Исходный исходный латекс test.tex.txt

Привет, @jpallen , просто хочу сообщить, что, похоже, проблема с Sharelatex решается, когда я переключаю компилятор на XeLatex.

Мы немного углубились в это в ShareLaTeX, и похоже, что патч выше (https://github.com/mozilla/pdf.js/pull/7482 by @brendandahl) находится на правильных строках с точки зрения перемещение персонажей в зону личного пользования, но не охватывает всех необходимых случаев. PDF-файлы, созданные ps2pdf, работают, но PDF-файлы, созданные непосредственно pdflatex, по-прежнему имеют эту проблему с отображением.

Если мы наивно переместим _everything_ в область частного использования (например, https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in- private-use-area), то он отображается правильно. Однако это всего лишь пример отладки, поскольку я считаю, что это плохая идея.

На этом этапе наши знания достигают предела, и мы не знаем, как определить правильные символы для использования в частной области. Итак, что мы можем сделать, чтобы продвинуть это вперед?

Если мы наивно переместим все в область частного использования (например, brendandahl @ move-non-unicode-glyphs ... briangough: put-all-symbolic-chars-in-private-use-area), то это отобразится правильно. Однако это всего лишь пример отладки, поскольку я считаю, что это плохая идея.

Не проверяя вышеизложенное, я подозреваю, что это может привести к ухудшению рендеринга в _много_ PDF-файлах, поскольку это может (в основном) привести к отключению хинтинга для _все_ символических шрифтов в некоторых средствах визуализации шрифтов. (Обратите внимание, что многие шрифты утверждают, что являются символическими, даже если на самом деле это не так.)

На этом этапе наши знания достигают предела, и мы не знаем, как определить правильные символы для использования в частной области. Итак, что мы можем сделать, чтобы продвинуть это вперед?

Поскольку в проблемных случаях используются обычные шрифты Type1, я все же думаю, что правильным решением _могут_ быть обеспечение правильной информации Charset / Encoding при преобразовании шрифтов Type1 в Type1Font_wrap .

@jpallen, я думаю, нам нужно распознавать шрифты, которые генерируются латексом, и эти шрифты являются символами (например, по имени или способу их создания), но они не должны распознаваться как таковые в остальных случаях.

Отсутствие перемещения _все_ символов в частную область дает нам некоторые преимущества, например, возможность использования шрифтов в элементах управления вводом, лучшую инструментацию и способность движка отбрасывать недопустимые глифы или шрифты и при этом получать несколько читаемый текст. Поэтому знание того, является ли глиф символом, является ключевым моментом.

Предварительная идея, основанная на PR # 7482, могла бы, возможно, заключаться в перемещении символов в PUA, когда мы не можем быть уверены, что данные toUnicode верны; например, что-то вроде этого: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

Большой! Я пробовал новый патч в Snuf fleupagus: issue-2594, и, похоже, он отлично работает для моего тестового примера и различных документов pdflatex, которые я пробовал. : +1:

В качестве теста я развернул его в рабочей среде в программе просмотра PDF-файлов на сайте появятся ли сегодня какие-либо неожиданные проблемы.

Мы протестировали этот патч (https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594) в производственной среде за последние 3 недели, и он устранил проблемы с отображением шрифтов LaTeX для нам, без каких-либо других проблем. Было бы здорово, если бы его можно было включить, спасибо. : +1:

Я начал просматривать # 7705 и начал задаваться вопросом, почему мой оригинальный патч также не исправляет test-pdftex.pdf . Просто глядя на данные шрифта, похоже, что pdf.js должен переместить большинство глифов из DVFZZA+CMEX10 в область частного использования, поскольку большинство из них не имеют действительного имени глифа для значений Unicode. Например, один из проблемных глифов (charcode = 110 name = 'braceleftBig') не имеет значения Unicode, но был сопоставлен с 'n'. Проблема, похоже, возникает, когда мы создаем карту Unicode, она правильно содержит 68 значений с глифами, которые имеют соответствующие значения Unicode, но после его создания мы добавляем обратно все исходные значения кодировки, поэтому 110 заполняется с помощью 'n'.

Я не совсем уверен, какое здесь правильное исправление, потому что, если мы удалим код для добавления значений обратной кодировки, наш выбор текста будет регрессировать с https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55

Может быть, у @Snuffleupagus есть мысли ...

_Как следует из https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210, предыдущая версия PR # 7705 содержала слишком упрощенное решение.

Таким образом, я собрал новую (и для меня, скорее всего, последнюю) попытку исправить это, которую можно проверить с помощью: http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html.
Было бы очень полезно, если бы люди, которые в настоящее время затронуты этой проблемой, могли протестировать последнюю версию PR # 7705 и сообщить, достаточно ли этого для решения этой проблемы!

Хорошо работает с test-pdftex.pdf, мы попробуем развернуть его в производственной среде на

Хорошо работает с test-pdftex.pdf, мы попробуем развернуть его в производственной среде на

Как обсуждалось в IRC, обратитесь к http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 , мы хотели бы продвинуться вперед с PR # 7705 .
@briangough Есть ли у вас какие-либо результаты тестирования исправления в рабочей среде на ShareLaTeX?

Как упоминалось ранее в https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252, было бы очень полезно, если бы те, кто в настоящее время затронуты этой проблемой, могли помочь с тестированием предлагаемого решения, что можно сделать с помощью например, превью в http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html, и сообщите, устраняет ли он эти проблемы!

Мы хотели бы получить PR # 7705, но нам действительно нужно подтверждение исправления, прежде чем это сделать.

Извините за задержку. Патч работает нормально - никаких нареканий от наших пользователей, спасибо.

Закрытие согласно исправлению # 7705, спасибо @Snuffleupagus и @brendandahl!