Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Content type word

Работа с phpWord. Заполнение шаблона договора docx

Шаблон договора для phpWord

Начну с постановки задачи. А она довольно простая — работая над сайтом клиента по прокату автомобилей возникла необходимость несколько автоматизировать рутинные операции. В частности требовалось при оформлении аренды на сайте автоматически заполнять в договоре некоторые поля. Вот этим и займемся.

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

Итак, мы скачали phpWord, распаковали архив и залили на веб-сервер. В моем случае речь идет о версии 0.6.2 Beta.

phpWord заливка на сервер

Теперь нам необходимо подготовить сам шаблон. Для этого запускаем MS Word или даже Wordpad и набираем текст договора. Для примера я набросал тестовый договор, который выглядит вот так (кликабельно):

Давайте определимся, что в этом шаблоне мы поручим заполнять php скрипту. К примеру, пусть это будет номер договора с датой, а также ФИО продавца и номер паспорта. Теперь давайте превратим наш договор в шаблон, с которым будем работать дальше.

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

Замечательно. Теперь делаем следующее — на тех местах, где у нас данные, мы их удаляем и вставляем имена переменных в виде

Т. е. там, где у нас номер договора 123 мы пишем $ и т. д. для всех переменных. В итоге получится вот такой шаблон договора:

Шаблон договора для phpWord

Отнеситесь к этому внимательно — ошибок допускать нельзя. Сохраняем полученный шаблон под именем Template.docx (можно назвать по своему).

Внимание! При сохранении документа в Word 2010 поставьте чекбокс «Поддерживать совместимость с предыдущими версиями Word» иначе работать не будет.

Вот теперь наш шаблон готов, теперь давайте научим php заполнять его.

Создаем php файл (к примеру, index.php) со следующим содержимым:

Вот и все. Если теперь мы запустим выполним наш скрипт, то в итоге получим заполненный данными шаблон договора:

Как видно, скрипт успешно заполнил шаблон, вот только с русскими символами беда — они выглядят не так, как задумывалось. Как решить эту проблему читайте в статье.

На этом все. Надеюсь, что хоть немного помог читателю разобраться с заполнением docx файлов на php. Для изучения все материалы можно скачать в виде архива.

Меток нет. Похожие записи

  • No related posts.

8 комментариев: Работа с phpWord. Заполнение шаблона договора docx

Спасибо за статью! Много прочитала, но помогла именно ваша
А как быть, чтобы отдать полученный документ на скачивание, а не сохранять на жесткий диск?
Я делаю:

$word = new PHPWord();
header(‘Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document’);
header(‘Content-Disposition: attachment;filename=»document.docx»‘);
header(‘Cache-Control: max-age=0’);

$template = $word->loadTemplate(dirname(dirname(__file__)) . «/documents/blancAct1.docx»);
$template->setValue(‘rrr’, ‘замена’);
$writer = PHPWord_IOFactory::createWriter($template, ‘Word2007’);
$writer->save(‘php://output’);
Отдает битый пустой файл

У меня тоже PHP Word на выходе отдает какой-то битый файл, который не открывается в Word. При этом файл не пустой, но почему-то имеет неверный формат. При просмотре файла в Editre- в нем полно всякой ерунды, включая заголовки сайта, меню, куки php. Не знаете в чем проблема? Почему библиотека phpword не работает как надо?

метод saveAs() надо вызвать, тока тогда сохранит изменения

А как вообще эту библиотеку прикрутить к тому же денверу, сказано скиньте в ваш вебсервер, куда уже только не кидал не видит он её. кидал homeдоменwww кидал так же homelicalhost

А процедурным стилем как вносить данные в документ?

Не работает ваш пример.

скачал ваши исходники вот код index.php
loadTemplate(‘Template.docx’);
$document->setValue(‘d_num’, ’777′);
$document->setValue(‘d_date’, ’04.10.2014′);
$document->setValue(‘last_name’, ‘Никоненко’);
$document->setValue(‘name’, ‘Сергей’);
$document->setValue(‘surname’, ‘Васильевич’);
$document->save(‘Template_full.docx’);
?>

вот эта строка вызывает подозрения require_once ‘PHPWord.php’; вы хотите подключить файл ‘PHPWord.php’ которого нет,среди скачанных файлов, что вообще за бред? зря только время потратил.

А скачать по самой первой ссылке что мешает?

Общее замечание. Статья относится к библиотеке 2011 года PHPWord. Она была такая, и исходники есть, и всё так. На гитхабе сейчас лежит её далёкий потомок PhpWord. В нём изменено очень много чего (например, не надо кривить исходники ради корректной работы с русским языком). И, в частности, пример выглядит радикально по-другому:

require_once(‘vendor/autoload.php’); // ставится ТОЛЬКО через Composer!
$_doc = new PhpOfficePhpWordTemplateProcessor(‘Template.docx’);
$_doc->setValue(‘d_num’, ’10/29-77-Ю’); //номер договора
// вывод непосредственно в браузер
header(‘Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document’);
header(‘Content-Disposition: attachment;filename=»dogovor.docx»‘);
header(‘Cache-Control: max-age=0’);
$_doc->saveAs(‘php://output’);
die;

Думаю, это замечание (о наличии новой версии либы с новыми вызовами) надо добавить в описание. Кому что удобнее: свежая либа с композером и хреновой горой пхпового мусора, или старая, но с багами, пусть решает сам.
dixi

4 The Content-Type Header Field

The Content-Type header field is used to specify the nature of the data in the body of an entity, by giving type and subtype identifiers, and by providing auxiliary information that may be required for certain types. After the type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute/value notation. The set of meaningful parameters differs for the different types. The ordering of parameters is not significant. Among the defined parameters is a «charset» parameter by which the character set used in the body may be declared. Comments are allowed in accordance with RFC 822 rules for structured header fields.

In general, the top-level Content-Type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a Content-Type of «image/xyz» is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format «xyz». Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype — such an action might be reasonable for unrecognized subtypes of text, but not for unrecognized subtypes of image or audio. For this reason, registered subtypes of audio, image, text, and video, should not contain embedded information that is really of a different type. Such compound types should be represented using the «multipart» or «application» types.

Parameters are modifiers of the content-subtype, and do not fundamentally affect the requirements of the host system. Although most parameters make sense only with certain content-types, others are «global» in the sense that they might apply to any subtype. For example, the «boundary» parameter makes sense only for the «multipart» content-type, but the «charset» parameter might make sense with several content-types.

An initial set of seven Content-Types is defined by this document. This set of top-level names is intended to be substantially complete. It is expected that additions to the larger set of supported types can generally be accomplished by the creation of new subtypes of these initial types. In the future, more top-level types may be defined only by an extension to this standard. If another primary type is to be used for any reason, it must be given a name starting with «X-» to indicate its non-standard status and to avoid a potential conflict with a future official name.

In the Extended BNF notation of RFC 822, a Content-Type header field value is defined as follows: Note that the definition of «tspecials» is the same as the RFC 822 definition of «specials» with the addition of the three characters «/», «?», and «=».

Note also that a subtype specification is MANDATORY. There are no default subtypes.

The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent. Parameter values are normally case sensitive, but certain parameters are interpreted to be case- insensitive, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the «access- type» for message/External-body is not case-sensitive.)

Читать еще:  Исправление ошибок word

Beyond this syntax, the only constraint on the definition of subtype names is the desire that their uses must not conflict. That is, it would be undesirable to have two different communities using «Content-Type: application/foobar» to mean two different things. The process of defining new content-subtypes, then, is not intended to be a mechanism for imposing restrictions, but simply a mechanism for publicizing the usages. There are, therefore, two acceptable mechanisms for defining new Content-Type subtypes:

  • Private values (starting with «X-«) may be defined bilaterally between two cooperating agents without outside registration or standardization.
  • New standard values must be documented, registered with, and approved by IANA, as described in Appendix F. Where intended for public use, the formats they refer to must also be defined by a published specification, and possibly offered for standardization.

The seven standard initial predefined Content-Types are detailed in the bulk of this document. They are: text textual information. The primary subtype, «plain», indicates plain (unformatted) text. No special software is required to get the full meaning of the text, aside from support for the indicated character set. Subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes thus include any readable word processor format. A very simple and portable subtype, richtext, is defined in this document. multipart data consisting of multiple parts of independent data types. Four initial subtypes are defined, including the primary «mixed» subtype, «alternative» for representing the same data in multiple formats, «parallel» for parts intended to be viewed simultaneously, and «digest» for multipart entities in which each part is of type «message». message an encapsulated message. A body of Content-Type «message» is itself a fully formatted RFC 822 conformant message which may contain its own different Content-Type header field. The primary subtype is «rfc822». The «partial» subtype is defined for partial messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through mail transport facilities. Another subtype, «External-body», is defined for specifying large bodies by reference to an external data source. image image data. Image requires a display device (such as a graphical display, a printer, or a FAX machine) to view the information. Initial subtypes are defined for two widely-used image formats, jpeg and gif. audio audio data, with initial subtype «basic». Audio requires an audio output device (such as a speaker or a telephone) to «display» the contents. video video data. Video requires the capability to display moving images, typically including specialized hardware and software. The initial subtype is «mpeg». application some other kind of data, typically either uninterpreted binary data or information to be processed by a mail-based application. The primary subtype, «octet-stream», is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. Two additional subtypes, «ODA» and «PostScript», are defined for transporting ODA and PostScript documents in bodies. Other expected uses for «application» include spreadsheets, data for mail-based scheduling systems, and languages for «active» (computational) email. (Note that active email entails several securityconsiderations, which are discussed later in this memo, particularly in the context of application/PostScript.) Default RFC 822 messages are typed by this protocol as plain text in the US-ASCII character set, which can be explicitly specified as «Content-type: text/plain; charset=us-ascii». If no Content-Type is specified, either by error or by an older user agent, this default is assumed. In the presence of a MIME-Version header field, a receiving User Agent can also assume that plain US-ASCII text was the sender’s intent. In the absence of a MIME-Version specification, plain US-ASCII text must still be assumed, but the sender’s intent might have been otherwise.

It should be noted that the list of Content-Type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially.

Файлы MS Office «изнутри». Open Packaging Conventions. Базовые принципы. Компоненты и связи

Сегодняшним постом я хочу начать еще одну серию. В ней я планирую немного поговорить о том, что представляют собой файлы MS Office “изнутри”, а также об инструментах (утилитах и библиотеках) для их создания, изучения, изменения, …

Прежде чем перейти к содержательной части некоторый предваряющий disclaimer (традиционно ):

Я в основном буду касаться современных офисных форматов, тех что появились в редакции Office 2007. Их еще называют XML-based форматами, в противовес старым бинарным (и это закрепилось в расширении файлов: docx, pptx, xlsx, … – в противовес doc, ppt, xls, …), ну или просто Open XML

Некоторая часть статей (по крайней мере в самом начале) будет основана на материалах Open XML Developer Workshop (контент и видео), который вел Doug Mahugh. Если вам не хочется ждать моих статей рекомендую обратиться к этим материалам

Еще одним хорошим подспорьем для изучающих Open XML будет книга Воутер Ван Вугт. OpenXML. Кратко и доступно. Ранее она в электронном виде была доступна в блоге евангелиста Microsoft Владимира Габриеля, но теперь – увы. Так что, если вам интересно и не хочется тратить время на поиск, можете взять здесь.

Вроде бы все. Можно приступать.

Что такое Open Packaging Conventions?

В двух словах, это формат контейнеров, поддерживающих хранение как структурированных (XML), так и неструктурированных компонентов (картинки, видео, бинарные компоненты, …) в одном файле.

Краткая но довольно информативная статья об OPC есть на wikipedia.

Что можно сказать в общем об этом стандарте/формате? Я бы выделил такие моменты:

● Формальное описание является частью ECMA-376. Office Open XML File Formats, более конкретно – второй частью Part 2 — Open Packaging Conventions.

● Сам стандарт описывает только структуру хранения и самые общие метаданные (типа автора, даты,…) поэтому потенциально в таком контейнере можно хранить практически что угодно.

Например, вот несколько форматов, основанных на OPC от самого Microsoft:

o .docx, pptx, xlsx, .vsdx – форматы Word, Power Point, Excel и Visio

o .xps (.oxps) – формат “электронной бумаги” или формат c фиксированной разметкой, предназначенный для передачи документов без искажения форматирования (в чем-то аналог PDF).

o .vsix – формат расширений Visual Studio, начиная с версии 2010

o .cspkg – формат пакетов для Windows Azure Cloud Services

o .appx – формат пакетов приложений Windows Store (для Windows 8)

Что представляют собой контейнеры в OPC?

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

Т.е. в чистой теории, контейнер в OPC может храниться единый файл, а может, например, как набор отдельных ресурсов на Web-сервере. Но (!) на текущий момент определена только 1 реализация – в виде единого файла ZIP-архива.

Структура контейнеров в OPC

Вообще говоря, концептуальная схема пакетов в Open Packaging Conventions очень проста, она включает в себя всего два элемента:

компоненты (parts), которые собственно и содержат хранящийся контент (любой: xml, image, video, …)

отношения (relationships), которые определяют

o предназначение (смысл/семантику) каждой части

o отношения между частями, а также между частями и пакетом целиком

Компоненты

Как уже было сказано выше компонент в OPC это и есть основная единица хранения контента. Каждый компонент характеризуется 2-я составляющими: именем и типом содержимого.

Имя компонента состоит из набора сегментов, начинающихся с прямого слэша (“/”), вот несколько примеров:

В спецификации приведены более формальные правила построения имен, из которых я укажу только основные (на мой взгляд):

● все имена должны начинаться с прямого слэша (“/”) и не должны им заканчиваться

● имя недолжно содержать пустых сегментов (т.е. /images//image1.jpg – неправильное имя)

«, «:«, «@»

● ни одно имя компонента не должно строиться как имя уже существующего компонента + новый сегмент. Т.е. если есть компонент с именем /abc/abc, то компонент с именем /abc/abc/a существовать не может, зато вполне может существовать компонент с именем /abc/abcde

● имена могут записываться Unicode-символами или использовать кодирование в виде /a/%D1%86.xml

Тип содержимого компонента задается в соответствии с RFC 2616 (раздел Media Types) т.е. в виде / :

Связи

Любой компонент в пакете (а также сам пакет) может ссылаться на другие компоненты или некоторые ресурсы за пределами пакета. Для представления этих ссылок введен специальный механизм связей. По большому счету, связи позволяют решить 2 задачи:

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

● поменять набор связей компонента, не меняя его содержимого (которое может быть, например, зашифровано или защищено цифровой подписью)

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

Информация о связях для каждого компонента (а также самого пакета), хранится в специальных компонентах связей (relationships parts) тип содержимого которых application/vnd.openxmlformats-package.relationships+xml

Имена компонентов связи строятся из имени исходных компонент, к которым:

● добавляется предпоследний сегмент с именем _rels

● дописывается “расширение” .rels

Связи самого пакета хранятся в специальном компоненте с именем /_rels/.rels

Например, если в пакете у нас есть компонент с именем /document/mainPart.xml и два связанных компонента с картинками (пусть их мена будут /images/image1.png и /images/image2.jpeg), то пакет для них будет иметь следующую структуру:

Содержимое компонента связи представляет собой XML следующего формата:

Как уже наверняка понятно из приведенного фрагмента, каждый тэг определяет одну связь. Его атрибуты:

Id

Идентификатор связи. На него ссылаются из содержимого компонент, когда необходимо использовать конкретную связь.

Type

Тип связи. По сути дела тип указывает семантику связи. Например, две разных связи могут указывать на 2 компонента типа image/jpeg, но одно изображение будет картинкой в тексте документа, а второе – миниатюрой (thumbnail) всей страницы целиком.
В качестве типа может использоваться любой валидный URI

TargetMode

(Необязательный) Принимает одно из возможных значений:

· Internal (значение по умолчанию) – указывает, что связь ссылается на компонент пакета

· External – связь указывает на ресурс за пределами пакета

Target

Адрес ресурса или компонента на который ссылается связь

Важный момент: для обращения к компонентам и внешним ресурсам можно использовать как абсолютные адреса (для компонент это будет их полное имя), так и относительные. В последнем случае полное имя компоненты рассматривается как путь в файловой системе, каждый сегмент, кроме последнего – имя “папки”, а последний – имя “файла”. Вот несколько примеров такой адресации:

Имя исходного компонента

Относительный адрес

Результирующий адрес

Вот, по большому счету и все, что касается модели пакета в OPC. Осталось сказать несколько слов о физической реализации пакетов

Пакеты на основе ZIP-архивов

Как уже было сказано выше, в спецификации OPC определена только одна реализация пакетов – на основе ZIP архивов. Она достаточно проста, поэтому я приведу её обзорно:

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

● для хранения типа контента каждого компонента в архиве создается специальный файл с именем [Content_Types].xml

Внутри файла [Content_Types].xml хранится XML следующего вида:

Собственно, общая схема, я думаю, понятна и так: для описания типов используется два подхода:

● указание типа по расширению (тэг )

● явное указание типа для конкретного компонента (тэг )

Как заглянуть внутрь OPC-пакета?

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

Вот несколько способов как это можно сделать:

Прямой (“рукопашный”) способ. Т.к. физическая реализация OPC есть ни что иное, как обычный ZIP-архив, то самый простой способ его изучить – распаковать и работать как с обычной папкой (ну или воспользоваться любимым архиватором).

o Плюс подхода – будете глубже понимать устройство.

▪ Сложно отслеживать связи между компонентами (а именно они образуют структуру, а вовсе не “папки” архива)

▪ Довольно муторно редактировать, если захочется экспериментов (нужно добавлять файлы для компонентов, править файлы связей да еще и не забывать про указание типа контента, если он не стандартный)

Open XML Package Editor Power Tool for Visual Studio 2010. Расширение для Visual Studio. Умеет открывать файлы в формате OPC, показывать и редактировать их логическую структуру (добавлять/удалять/редактировать компоненты и связи). Для редактирования содержимого компонент используется редакторы самой VS, что очень удобно для экспериментов (XML редактор в VS явно не самый плохой, особенно если в наличии есть хорошие XSD-описания).

▪ Так и не нашел способа создать пакет с 0 (но это редко нужно, да и обходится созданием пакета вручную).

▪ Требует Visual Studio.

▪ Работает только в 2010 версии VS. Увы, для более новых версий студии пакет так и не обновился, хотя почти наверняка он заработает без доработок в любой последующей. А доработать установщик пакета руками не получается, т.к. это не обычный vsix

Standalone приложение от Воутера Ван Вугта Open XML Package Explorer. По возможностям оно близко к предыдущему расширению для VS, но не требует ничего для установки, кроме .Net 3.0. У него даже есть встроенный редактор XML, правда уступающий редактору от VS. К сожалению, приложение давно не обновлялось имеет ряд неприятных ошибок… но пользоваться можно.

Пара слов в заключение

Как видите, стандарт OPC в своей основе довольно прост и функционален. Однако остались еще ряд нераскрытых тем. В частности мы не рассмотрели ряд возможностей, заложенных в формат OPC:

● базовые метаданные пакета (core properties)

● иконки пакета (thumbnails)

● цифровые подписи (digital signatures)

Ну и, конечно, мы еще ни слова не проговорили об API для работы с OPC пакетами.

Библиотека PHPWord: основные возможности

Библиотека PHPWord, находящаяся уже почти год в стадии бета-тестирования 1) , предоставляет возможность создания сложных документов формата OOXML (*.docx). Рассмотрим основные возможности этой библиотеки. Для начала работы достаточно распаковать архив с библиотекой в каталог с создаваемым вами документом PHP и подгрузить основной класс библиотеки, расположенный в файле PHPWord.php:

Свойства документа и шрифт по-умолчанию

Создание документа начинается с объявления экземпляра класса PHPWord. Конструктор не требует передачи аргументов:

Далее следует задать название и размер шрифта по-умолчанию:

В рассматриваемой версии до применения указанных выше функций шрифтом по-умолчанию является Arial размером 20 пунктов. Теперь можно задать время создания документа, имя автора и так далее:

По-умолчанию в качестве даты создания и изменения документа указывается текущее время, а остальные свойства заполняются пустыми значениями. Если требуется указать конкретную дату создания или изменения, используйте функцию mktime или любую другую функцию, возвращающую время в стиле Unix.

Создание разделов

Основным элементом документа Word является Раздел. Раздел представляет собой прямоугольную область, внутри которой помещаются остальные элементы страницы: текст, изображения, таблицы и т.д.

Раздел может иметь книжную или альбомную ориентацию, настраиваемые поля (margins), настраиваемые цвета границ раздела и их толщину (на рисунке показана пунктиром):

Для создания раздела существует функция createSection. В качестве внутренних единиц используются типографские твипы. Если вам непривычно указывать размеры в твипах, можно написать простую функцию, преобразующую миллиметры в твипы:

Указанные в таблице параметры могут быть переданы в виде массива при создании раздела.

. или могут быть установлены по-отдельности после создания раздела:

Добавление текста

Добавление блока текста

Под блоком текста понимается отрывок текста, имеющий одинаковое форматирование (цвет, размер шрифта и т.п.). Для создания блока текста в выбранном разделе используйте функцию addText:

Здесь $text — добавляемый текст, необязательный параметр $fontStyle — имя определенного ранее текстового стиля, необязательный параметр $paragraphStyle — имя определенного ранее стиля абзаца.

Изменение форматирования текста

Форматирование текста, как и форматирование раздела, может осуществляться при его создании.

. или устанавливается после создания предназначенными для этого методами:

Ниже приведен полный список доступных параметров форматирования текста:

Названия параметров должны употребляться с соблюдением регистра. В случае параметров underline и fgColor применение значений, не указанных в таблице, не допускается.

Cписок доступных параметров форматирования абзаца:

Определение стилей текста и абзаца

Вместо того, чтобы каждый раз передавать в функцию createText массив с параметрами, вы можете создать именованный стиль, а затем указывать только название этого стиля:

Здесь $styleName — заданное вами имя стиля, $fontStyle — массив, содержащий определение стиля. После создания стиля его имя можно использовать при создании блоков текста, например:

Аналогичным образом осуществляется создание стиля абзаца:

Группировка блоков текста в абзац

Блоки текста с различным форматированием могут быть объединены в абзац заданного вида. Для этого применяется команда createTextRun:

Необязательный параметр $paragraphStyle — массив со стилем абзаца или название созданного ранее именованного стиля.

Добавление заголовков

В библиотеке имеются отдельные функции для добавления заголовков (addTitle) и задания их стилей (addTitleStyle). Применение заголовков вместо форматированных блоков текста необходимо в том случае, если вы хотите добавить в документ автоматически создаваемое оглавление, поскольку в оглавление включаются только заголовки, а не обычные блоки текста. При добавлении заголовков создание стилей заголовков обязательно:

Здесь $titleLevel — уровень заголовка, для которого задается стиль (обычно от 1 до 6), $fontStyle — массив со стилем форматирования заголовка, $paragraphStyle — массив со стилем форматирования абзаца. Как видите, форматирование можно не трогать, но сам стиль заголовка требуемого уровня должен быть обязательно создан. Добавление заголовка делается так:

По-умолчанию создается заголовок 1 уровня.

Добавление ссылок

Добавление ссылок мало чем отличается от добавления обычного текста. Для добавления ссылки используется команда:

Разрыв строки и страницы

Для принудительного переноса строки используйте синтаксис:

Необязательный параметр $num, по-умолчанию равный 1, указывает сколько переносов строки необходимо сделать. Для принудительной вставки разрыва страницы выполните:

Добавление оглавления

Для добавления оглавления используется функция addTOC:

Здесь $fontStyle — форматирование текста, определенное одним из ранее указанных способов, $tocStyle — массив со стилем оформления оглавления, возможные параметры которого приведены в таблице: ^ Параметр ^ Описание ^

Добавление списков

Присутствует возможность добавления нумерованных и ненумерованных списков в документ. Для добавления элемента списка используйте код:

Здесь $text — текст добавляемого элемента списка, $depth — глубина вложенности элемента в списке (от 1 до 9, по-умолчанию равна 1), $textStyle — форматирование текста списка одним из предложенных ранее способов, $listStyle — форматирование самого списка при помощи массива параметров, $paragraphStyle — форматирование абзаца. На данный момент не существует функции addListStyle, поскольку у списков пока может изменяться только один параметр:

Добавление таблиц

Важной частью документа Word являются таблицы. Для создания таблицы в PHPWord выполните:

Необязательный аргумент $tableStyle — массив с описанием стиля таблицы или название такового, определенного методом addTableStyle:

Аргументы: $styleName — название стиля, $tableStyle — массив с определением стиля, $firstRowStyle — массив с определением стиля ячеек 1 строки (шапки) таблицы. Ниже приведена таблица возможных стилевых параметров таблицы в целом: ^ Параметр ^ Описание ^

Теперь в созданную таблицу можно добавить ячейки. Как и в XHTML, вначале нужно создать строку.

. затем добавить ячейки и заполнить их форматированным текстом.

. или сделать то же самое одной командой.

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

Блог Vaden Pro

Список MIME-типов

  • 1289 просмотров

Характеристика значения

Общее определение

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

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

Управление и контроль этим процессом осуществляется благодаря Многоцелевым расширениям почты Интернета (сокращенно MIME от английского языка).

MIME – особый список данных и расширений для них, с помощью которых осуществляется пересылка информации в сети Интернет различного вида. Касательно языка программирования HTML, данная спецификация используется для управления отправкой форм и других информационных объектов, с возможностью их размещения на веб странице.

Перечень MIME-типов

В случае не определения одного из перечисленных форматов в спецификации файлу автоматически присвоится тип text/plain.

Что касается файлов HTML, то они распознаются протоколом без особых проблем. Им присваивается расширением text/html. Особая ситуация возникает при отправке файла формата XHTML. Для использования всех возможностей такого файла необходимо указывать для файла расширение application/xhtml+xml. В противном случае файлу присвоится согласно протоколам MIME расширение файла HTML, то есть text/plain.

Для примера рассмотрим работу с сервером Apache. Используем особую команду для работы в корневой папке сайта в файле .htaccess. Запись будет выглядеть следующим образом

Запись для работы с языком PHP выглядит несколько иначе. В заголовок записывается конструкция следующего плана

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

Internet Explorer версией не выше 9.0 не может распознать документы типа application/xhtml+xml. остальные версии этого браузера считывают эту запись нормально, в том числе и все остальные браузеры.

Также не стоит злоупотреблять использования файла такого типа. Он станет полезным только если используется математическая символика MathML. Также такой формат будет очень полезен при использовании модуля графиков-векторов — SVG. В противном случае рациональней ограничиться файлом HTML, который расширит число браузеров, которые без проблем считают информацию с вашего веб-ресурса.

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

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

Интересный факт про историю развития MIME-протокола.

Правообладатели MIME были очень удивлены и восторженны после того, как получили письмо от создателя протокола IMAP – Марка Криспина. Он прислал им письмо форматом mbox в качестве проверки MIME-протокола. По словам представителей MIME, это было сумасшедшее письмо с тридцатью вложенными друг в друга составляющими частями. Однако, они также отметили, что это лучшая проверка для протокола MIME.

Ссылка на основную публикацию
Adblock
detector