Apache OpenOffice 3.4 の新機能について
The Apache OpenOffice 3.4 features can be split in two separate areas based on the timeline by the change step from OpenOffice to Apache OpenOffice. One set was already present, one set is the result of work based on Apache since then.
OpenOffice.org 3.4 ベータからの新機能
This features were already part of the OpenOffice 3.4 beta:
(preparing data for this place from here)
Apache OpenOffice 3.4 の新機能
This features are the result of the work at Apache on OpenOffice since the change:
Line Cap プロパティーのサポート
Now you can add a cap to the ends of a line. Such caps are not only known in the ODF1.2 standard but in HTLM5 and SVG too. Also other Office Sites provide caps in different styles to be added to thick lines.
Three styles exist
- without a cap, called 'Butt' in programming and 'Flat' in UI (as in MS Office)
- with a round cap, called 'Round'
- with a rectangle cap, called 'Square'
The property value 'Flat' corresponds to the old behavior and is now the default.
The caps are added to the lines, so that the total length of the lines increases with two-times a half line width.
Select the value from a drop-down-list in the line property dialog, just beside the settings for corner style. The new property is only available in contexts, where the corner style is active too.
If a line is dashed, the single dashes get caps too. Hereby a dot is treated as dash. You can style not only pure lines and curves, but the border of graphic objects as well.
The next example shows the new property applied to a connector. Left side without cap, in the middle with 'round' cap, and on the right side with 'square' cap.
The caps are available for 3D-objects too, when you turn on lines and make them thick. The example shows lines, which are styled to look “dotted”.
and a zoom…
Linecaps defined in svg-graphics are supported, so that those graphics look like in modern browsers.
ODF 1.2 のサポート
AOO supports ODF 1.2, which has many benefits, one of which is its extended cryptography options (e.g. AES encryption and SHA256 message digests).
Better UI Defaults for Draw と Impress のUIデフォルト改善
ODF Calc で新しい条件関数をサポート
Support conditional functions COUNTIFS, SUMIFS, AVERAGEIF and AVERAGEIFS
PDFs containing monochrome bitmaps are smaller now
PivotTable (formerly known as DataPilot) is no longer limited in the number of fields
Better interoperability with other applications supporting the import of CSV (Comma Separated Values) files as the style for exporting strings is configurable now
Printing via PDF (if the system supports it) allows object transparency to be handled directly by the printer subsystem
Support for shear transformations for GraphicObjects (Blog entry)
GraphicObjects which get created when inserting graphics in Draw/Impress and Calc support now not only rotation but also shear, slant and distort. The visualization during interactions got improved, also the break for vector-based GraphicObjects to draw objects was improved. Writer has it's own GraphicObjects, the ones from the other applications can be copied to it as workaround.
Support for attributes and transformations for OLEObjects (Blog entry)
OLEObjects (OLE is for Object Linking and Embedding) in Draw/Impress and Calc support now all draw attributes and geometrical transformations. They can have line style, fill style, shadow and text. They support all kinds of transformations, e.g. rotations and shear. This is handy for e.g. having a mathematical formula shown rotated by 90 degrees or adding a border to a chart. Break to draw objects is also enhanced.
Enhanced crop support for GraphicalObjects
Crop for GraphicObjects now works correctly together with horizontal and/or vertical mirroring in all applications.
Support for Scalable Vector Graphics (SVG) (Blog entry)
Svg is now supported as content for GraphicObjects in all applications. The new implemented generic Svg interpreter supports Svg format 1.1. The geometric content is internally processed as vector data in all usages, e.g. PDF export and printing, which guarantees good visualization quality. Svg graphics can be broken to draw objects and be processed further. A blog entry can be found here.
ODF で MultiImage をサポート
For Svg support it was necessary to allow multiple image representations for one GraphicObject to be present in the ODF file format, e.g. a pixel graphic and the original Svg is written in case of a GraphicObject with Svg content. This allows to stay compatible with other and older ODF supporting applications. The number of images for one GraphicObject is not limited; applications using this may choose the image with the format which supports it's purpose best, e.g prefer to use a pixel graphic for ODF viewers. AOO 3.4 uses a weighting function which prefers pixel images with transparency over such without and vector formats over pixel formats.
Enhanced chart visualisation
The visualization quality of charts has been enhanced by using a new mechanism for more direct visualisation. This increases speed, reduces memory usage and enhances chart visualisation in all visualisations, including PDF export and printing.
Now it supports nested tables, more character properties, sections, graphics for Wordpad, bookmarks, fields, drawings and OLE
新しい正規表現 (regexp) エンジン
The existing regular expression engine has been replaced by the ICU engine. This solves several bugs in "Find and Replace" with the old implementation and speeds up the search.
The new engine also offers better standards compliance especially regarding Unicode, which also means that some non-standard syntax extensions like
\> for word boundary matching are now deprecated. For the convenience of a smooth upgrade experience they get emulated by the
\b operator though.
See ICU regex syntax for expressions supported in the new regular expression engine. It is recommended to stay on the common ground though and regex flavors gives an overview where this common ground is. The modified syntax applies to macros too: regular expressions in macros that were relying on the deprecated syntax should be converted to use widely supported regex expressions.
Users of Japanese scripts should be aware that several non-trivial transliterations could behave slightly differently, especially when transliteration rules like "ProlongedSoundMark", "IterationMark", "Ignore-Width", "BaFa", "SeZe", "HyuByu", "IandEfollowedByYa" or "KiKuFollowedBySa" might be involved.
Startup is faster as the program now has enough initial knowledge about its components so that it doesn't have to start each of them