Веб-страницы печатным СМИ — решения?
В последнее время борясь с методами финализатора (чтобы избавиться от пулов соединений во время тестирования), я должен сказать, что финализатору не хватает многих вещей. Используя VisualVM для наблюдения, а также используя слабые ссылки для отслеживания фактического взаимодействия, я обнаружил, что в среде Java 8 выполняются следующие вещи (Oracle JDK, Ubuntu 15):
- Finalize не вызывается немедленно Finalizer (GC part) индивидуально владеет эталоном неуловимо
- По умолчанию сборщики пулов Garbage собирают недостижимые объекты
- Finalize вызывается в массе, указывая на деталь реализации, что есть определенная фаза мусора сборщик освобождает ресурсы.
- Calling System.gc () часто не приводит к тому, что объекты будут финализироваться чаще, это просто приводит к тому, что Finalizer быстрее узнает о недоступном объекте
- Создание дампа потока почти всегда приводит к запуску финализатора из-за высокой накладной кучи во время выполнения дампа кучи или какого-либо другого внутреннего механизма
- Швы финализации должны быть связаны требованиями к памяти (освободите больше памяти) или список объектов, помеченных для финализации рост определенного внутреннего предела. Поэтому, если у вас есть много объектов, которые будут завершены, фаза завершения будет срабатывать чаще и раньше по сравнению с несколькими
- . Были обстоятельства, при которых System.gc () запускает финализацию напрямую, но только если ссылка была местной и короткой жизнью. Это может быть связано с генерацией.
Final Thought
Метод Finalize ненадежен, но может использоваться только для одной вещи. Вы можете убедиться, что объект был закрыт или удален до сбора мусора, что позволяет реализовать отказоустойчивость, если обрабатываются объекты с более сложным жизненным циклом, включающие действие с истекшим сроком действия. Именно по этой причине я могу думать, что это стоит того, чтобы переопределить его.
5 ответов
Вы, возможно, услышали о PediaPress, компании, которая сделала "Wiki для печати" (т.е. PDF, но также и ODF) соглашения с Фондом Викимедиа. (См., "что Wikis Идет Печатаемый".) Их код разработан для работы с MediaWiki и является открытым исходным кодом.
Но! Это еще лучше, чем это. Проверьте этот bookmarklet. Можно использовать его для создания PDFs или ODFs любой публично доступной страницы MediaWiki (возможно, этому нужен API, который будет включен также...). И можно связать несколько страниц, от единственного MediaWiki или несколько MediaWikis, в единый документ. Это является довольно чертовски потрясающим в моей книге.:)
ETA: PediaPress поместили значительную работу в создание чего-то, что выглядит действительно хорошим читать. Это не просто эквивалент версии для печати MediaWiki, преобразованной в PDF.
Используя печать файлы CSS действительно гладкий подход к переформатированию страниц для печати.
Много людей отступает к PDF, потому что это может быть более мощным и легче.
Для большинства вещей, тем не менее, я думаю, что разметка CSS более проста и легка.
Посмотрите на источник для страниц в StackOverflow, и Вы будете видеть ссылки на media="print" (print.css) - ряд разрабатывает примененный только, когда браузер печатает страницу.
<link href="/Content/print.css" rel="stylesheet" media="print" type="text/css" />
Можно использовать их, чтобы скрыть navbars, реклама (или показать различную рекламу). Сделайте некоторое основное разбиение на страницы и т.д.
При необходимости в большем количестве управления вещами как поля необходимо выйти за пределы браузера (PDF, Word, XPS, и т.д.).
могло быть что-то для Вас. Это преобразовывает xml и страницы HTML к документам PDF.
mediawiki2latex проект предлагает решение.
страница Any MediaWiki может быть преобразована в PDF, Epub, Odt или LaTeX
, Это может использоваться онлайн на сервере, размещенном Фондом Викимедиа:
https://mediawiki2latex.wmflabs.org /
существует также опубликованная статья на проекте
http://www.tug.org/TUGboat/tb34-2/tb107huenniger.pdf
, источник доступен под GPL. Существует хорошо пакет Debian:
sudo apt-get install mediawiki2latex
mediawiki2latex -u https://en.wikipedia.org/wiki/Epimorphism -o output.pdf
evince output.pdf
Я записал MediaWiki для Пропитки латексом преобразователя, который пытается поддержать структуру документа исходного текста. Документ затем набирается с pdflatex для представления очень высококачественного, нумеровавшего страницы документа. Математическая разметка непосредственно представляется ЛАТЕКСОМ, таким образом, уравнения выглядят большими. ЛАТЕКС documentclass / таблица стилей настраивается от специализированных команд в Wiki для прямого управления полями, макетом страницы, шрифтами, дополнительные пакеты и так далее. Это упало бы в Вашей второй категории пользовательского сценария, а не универсальной платформы.
Существуют многие другие, такие как Extension:Pdf_Export, который использует htmldoc. В то время как это является более общим, это делает очень плохое задание разбиения на страницы и создает много висячих строк и висячих строк, не делает оптимального выравнивания текста и не делает индексов, чисел, самоссылок, и т.д. Кроме того, при использовании <математика> разметки в MediaWiki, это только включает низкие-res файлы PNG.
princexml специализирован для MediaWiki и представляет красивые документы, но не доступен в соответствии с Бесплатной лицензией. Так как это - продукт с закрытым исходным кодом, Ваша способность управлять выводом ограничена.