Сохранение и печать XPSDocument через Paginator (кажется) вызывают растеризацию содержания

GC Java, как предполагается, является "звуковым", но не обязательно сразу "завершен". Другими словами, это разработано так, чтобы это никогда не устраняло бы объекты, которые все еще доступны по крайней мере одним путем (и таким образом вызовите повисшую ссылку). Это не обязательно сразу завершено, так как это могло бы занять время, пока это не удаляет все, что может быть удалено.

я думаю, что большинство мифов о GC прибывает из неверного толкования того понятия. Многие люди сохраняют слишком многих переменные экземпляра живой, и это вызывает проблемы, но это - конечно, не проблема здесь.

Другие люди помещают локальные переменные в переменную экземпляра (например, путем передачи его для функционирования), и затем думают, что аннулирование локальной переменной так или иначе устраняет переменную, которая, конечно, неверна.

Наконец, существуют люди, которые сверхполагаются на GC и думают, что он сделал бы функциональное завершение работы для них (Например, близкие соединения, когда переменная удалена), который является, конечно, не случаем. Я думаю, что источник этой строки, "я действительно действительно сделан с ним, но я не уверен, как гарантировать это".

Так да, Вы корректны, что это является ненужным.

5
задан Alex Maker 24 July 2009 в 09:18
поделиться

1 ответ

Я узнал, как избежать своей проблемы, но не могу гарантировать, что решение применимо и к вашей. Фактически, кажется, что, используя две вложенные кисти VisualBrushes, проецируемые на ваш Visual, вы используете результаты в размытом выводе.

Нельзя избежать одной VisualBrush, которую мы используем при печати wpf: это та, которая применяется через наш Paginator, чтобы вырезать Наглядно и распределить на нескольких страницах. У меня также был один UserControl, который служил «шаблоном». Я рисую Rectangle с помощью VisualBrush нашей диаграммы в UserControl, и после этой операции сам UserControl рисует себя как Rectangle с помощью VisualBrush на страницах с помощью разбиения на страницы. Поскольку путь печати WPF использует XPS для печати, вы также можете создать XPSDocument, изменить тип файла на zip, извлечь его и проанализировать одну страницу вашего документа с помощью любого текстового редактора. Это очень поможет вам понять вашу проблему.

Я также подозреваю, что документ "растеризуется", когда содержимое VisualBrush не применяется с исходным соотношением высоты / ширины 1: 1, которое имеет Visual. Ошибки при вычислении размера привели к соотношению высоты / ширины 1: 0,9948 для примененной VisualBrush, и это привело к размытому результату (исключая проблему «вложенной VisualBrush»).

Это все еще только подозрение. Моя проблема была решена путем исключения «лишней» VisualBrush и соблюдения исходного соотношения сторон. Также можно предположить, что одна / или обе проблемы появляются только в сочетании с определенным визуалом / эффектом / преобразованием или даже с линейными кистями.

По крайней мере, я узнал одну вещь о пути печати WPF, когда дело доходит до таких проблем: Подумайте о том, что ваш материал всегда конвертируется в xps за сценой, а xps похож на wpf, но не поддерживает ничего, что делает wpf. Фактически, если я не неправильно понял, XPS послужил источником вдохновения для XAML в WPF.

Я также очень приветствую любой реальный ответ на эту проблему . Моя проблема решена, но я хочу знать, почему это произошло.

4
ответ дан 15 December 2019 в 01:08
поделиться
Другие вопросы по тегам:

Похожие вопросы: