Index ¦ Archives ¦ RSS > Tag: en

Adding visible signatures to existing PDF files in Draw

Estimated read time: 3 minutes

Draw now has support for adding visible signatures to an existing PDF file. This is in contrast with the old functionality which was limited to invisible signatures.

First, thanks to the Dutch Ministry of Defense in cooperation with Nou&Off who made this work by Collabora possible.

Motivation

The PDF format allows assigning a shape (a form xobject) to a digital signature in the PDF file, and if you use e.g. Adobe Acrobat, then it fills this shape with some visible information about the digital signature. Draw used to write a placeholder widget there (a 0x0-sized rectangle on the first page, at position 0x0). This is valid, but it’s not close to real-world signatures, where signing has a visual effect as well.

Results so far

Here is how this works in practice:

Figure 1. Demo of adding a visible signature to an existing PDF file in Draw

You can see how the 2 added signatures are visible and Adobe Acrobat confirms they are valid, too.

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

  • Signature lines were already working in Writer and Calc, this effort brings them to Draw, improving consistency.

  • Signing existing PDFs were already possible, this allows adding a visible signature with the correct markup. This is important for automated processing of PDFs, maybe even helps accessibility. (I think DocuSign doesn’t get this right currently.)

  • This uses the existing "export selected shape to PDF" code to produce that object, so it’s not a bitmap, but a scalable format. (As I know, DocuSign doesn’t do this, either.)

  • If you didn’t get the signature rectangle right for the first time, you can still move and resize it before the actual signing happens (Acrobat doesn’t support this currently, I believe.)

  • The generated object is locale-aware when it comes to the actual signature string and date format.

  • The feature works for multiple signatures and multiple pages as well.

  • The final step was this commit, with much more grounding before that one.

  • Note that the signing is a two step process: first you draw the signature rectangle and optionally finalize its position / size, and only then you use the Finish Signing button on the infobar to trigger the actual signing:

https://lh3.googleusercontent.com/TMPrD20O0PvPLB7Uru_mmxfeQTaWhJwNQ80jgLj23TWLNqkm44Ww8F9Azce0sEN1TzmjmmVW7MvHZTwtR6Us2H7qpzOSC07CQ0p_myEsM1WRQOToAEus0vsgpTh1yeD65YemFQvv_A=w640
Figure 2. After drawing a signature rectangle, before finishing the signing.

If you use a HW-based certificate, this second step will ask for your certificate PIN.

Want to start using this?

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.1).


Page-content-bottom vertical relation in Writer

Estimated read time: 3 minutes

Writer now has support for anchoring shapes relative to the bottom of the page content frame.

First, thanks to our partner SUSE for working with Collabora to make this possible.

Motivation

Users sometimes want to specify the vertical position of their shapes in text documents in a way that is relative from the bottom of the page content area. Also, this improves consistency, specifying a position that is relative from the top of the page content area is already possible.

Alternatively, it is possible to have the same calculated position when positioning from the top of the page content area. The downside of this approach is that the position changes when the page height changes. So if the user intention is to position a shape 2 cm above the bottom of the page content area and the page height changes, the shape has to be manually re-positioned. This manual re-positioning is not needed with the new page-content-bottom vertical relation.

For example, if a shape has a height of 10 cm and a 2 cm spacing is wanted between the bottom of the shape and the bottom of the page content area, the position can be set to -12 cm, and then the 2 cm spacing will be maintained, even after the page height changes.

Results so far

Here is how this works in practice:

Figure 1. Demo of a stable vertical position (relative to the bottom of the page content frame), during a page height change

You can see how the distance of the shape from the bottom is 2 cm, even if the page height changes.

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

  • the UNO API now supports a new PAGE_PRINT_AREA_BOTTOM relative orientation

  • the have the expected layout, SwToContentAnchoredObjectPosition::CalcPosition() now considers this from-bottom anchoring when handling the vertical relative orientation

  • the DOCX format already had a markup for this:

<wp:positionV relativeFrom="bottomMargin">
  <wp:posOffset>...</wp:posOffset>
</wp:positionV>

now the import/export code maps this markup to the new feature.

  • The UI allows setting a new "Page text area bottom" frame position. It turns out that the UI is quite nice here, it tries to prevent you from setting positions which would be outside the limits of the current page. This logic in SwFEShell::CalcBoundRect() now handles the new relative orientation.

  • The ODF filter now has a markup to represent the new vertical relation:

<style:graphic-properties ... loext:vertical-rel="page-content-bottom" .../>

There is a proposal to promote this from our extension namespace to normal ODF (thanks to Regina for the help there!).

Want to start using this?

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.1).


Export larger pages from Draw using PDF 1.6

Estimated read time: 2 minutes

Draw/Impress now has support for exporting larger page sizes into PDF. The previous limit was 200 " (508 cm), and now practically there is no such limit.

First, thanks Vector who made this work by Collabora possible.

Motivation

You can use Draw with a document which has a single page, which more or less acts as a canvas with unlimited size to handle vector graphics. The current limit of such a canvas in size is 600 x 600 cm. (And that can be increased further if there is demand without too large problems.)

Exporting such a document to PDF is a different matter, though. The specification (up to, and including version 1.5) says that the unit to specify sizes is points, and the maximum allowed value is 14 400. This means that there is no markup to describe that your page is 600 cm wide. PDF 1.6 (and newer versions) introduce a UserUnit markup to allow unlimited page size, and now Draw (and other apps) can use this to describe the increased size.

Another use-case can be a large sheet in Calc, exporting it to a single PDF page, so you can pan around easily on a touch device. If you have enough rows, then getting rid of this limit is helpful to deal with the large page height.

Results so far

Here is how a large page looks like now in Draw and then in Adobe Reader:

Figure 1. Export of 6m-wide.odg to PDF

You can see how both Draw and Adobe Reader show that the page width is larger than 200 ".

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

  • The PDF export already converts from an internal unit (e.g. Draw uses 100th millimeters, Writer uses twips) to PDF’s unit

  • The trick is that now PDF’s unit is no longer points all the time, but we can dynamically switch to a larger unit as needed.

Here is how the PDF markup looks like for a 600 cm wide page:

1 0 obj
<</Type/Page/Parent 4 0 R/Resources 11 0 R/MediaBox[0 0 8503.93700787402 396]
/UserUnit 2/Group<</S/Transparency/CS/DeviceRGB/I true>>/Contents 2 0 R>>
endobj

Notice how we still avoid values larger than 14 400, but now the UserUnit says that 1 unit means 2 points.

Want to start using this?

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.0).


Padded numbering in Writer, part 2

Estimated read time: 2 minutes

I already posted about the start of padded numbering support in Writer, there the focus was to insert 0 characters to pad up the result to 2 characters. Let’s see how that got extended in the recent past…

First, thanks Nicolas Christener who made this work by Collabora possible.

Motivation

Padded numbering is a style where you insert 0 characters in front of an otherwise normal (Arabic) numbering, making sure that the result always has at least N characters. Up to now, you had to number your content manually to have this effect, while Word supports this feature.

OOXML supports padding up to 2, 3, 4 and 5 characters. The news is now now it’s possible to not only pad up to 2 characters, but also to any number between 2 and 5.

Results so far

Here is how the current rendering of padded numbering looks like, with a custom prefix and suffix:

https://lh3.googleusercontent.com/JHqkVdHkLLkFV1Mrh5jR1FFqq8PvU3lmjuOrl6SwBnM-ygsbugL-FccMHIod9Uyj2-hAyADRX7VwozUHgzBTZTdo72FB_nuHzEH-iQngSl5ND0o6h1sZDTs1uv8H5cLNv0cHDgRv2A=w640
Figure 1. numbering-padded4.docx, current rendering

You can see how 0 is inserted before 999, but not before 1000 as this is the pad-to-4 case.

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

  • Padding to a custom number is not something that works in general, because both ODF and OOXML has a separate number format for each padding. So Writer supports the 4 cases Word supports, but (for now) not more.

  • Padding to 3 or more is more complicated than pad to 2, because OOXML has different markups for them.

Here is how the pad-to-2 markup looks like:

      <w:numFmt w:val="decimalZero"/>

And here is how you define pad-to-3:

      <mc:AlternateContent>
        <mc:Choice Requires="w14">
          <w:numFmt w:val="custom" w:format="001, 002, 003, ..."/>
        </mc:Choice>
        <mc:Fallback>
          <w:numFmt w:val="decimal"/>
        </mc:Fallback>
      </mc:AlternateContent>
  • This required taking the w14 branch when we hit such a conditional, we used to read the fallback branch previously.

  • This required mapping the data of the <w:numFmt> XML element not to an enumeration value, but to a pair of objects: the numbering format’s value and format.

The rest was reasonably straightforward, since the actual padding implementation just had to be generalized.

Want to start using this?

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.0).


My hack week at Collabora: (start of) padded numbering in Writer

Estimated read time: 3 minutes

As mentioned in a previous such report, a hack week is when we are allowed to hack on anything we want in LibreOffice for a few days at Collabora. I used this time to implement core support for padded numbering in Writer.

Motivation

Padded numbering is a style where you insert 0 characters in front of an otherwise normal (Arabic) numbering, making sure that the result always has at least N characters. Up to now, you had to number your content manually to have this effect, while Word supports this feature.

OOXML supports padding up to 2, 3, 4 and 5 characters. Padding up to 2 characters is the older feature, supported in DOC and RTF as well, so I focused on that piece.

Results so far

Here is how the current, the baseline and the reference rendering of padded numbering looks like:

https://lh3.googleusercontent.com/n-XvNw0xPkBK_u9eqVraa7meGxYPX8dpKtfmHkN54y60x5HvUhQBouGEnfLX3XjzQFDjG7oWhCGVvFLnINneGZwDIjB8FW1hgwYSEpWrt3kniLGeKNFAfpa_Y9NGHNadj50ecy3FVw=s300-p-k
Figure 1. numbering-padded2.docx, current
https://lh3.googleusercontent.com/BgSZhU4WNkwTvOejqbfaKSiEQUudnDCUeVaQ62xPETwzhP0-FUPsBZMrUrgwhfi3fSou3YIQ_Yb0tuDzJmeIxHk2LhOpS9ENvxwLCr3-aCn4rIS0e9vYOh2__cHAvP82-MUJzQS-Zg=s300-p-k
Figure 2. numbering-padded2.docx, baseline
https://lh3.googleusercontent.com/TXI-klcS5xzPUX0SaV_iqhweMcUX0aN1rc7rwwAbKdulmPYZ6wcYqcQTO94aHGZl_p4FuVSt_drCI1blKRHLupNjC6j08GjdppbkJ8o72xNmjpV_X2_LcPUgZmOfGBeUJRhDKptxqg=s300-p-k
Figure 3. numbering-padded2.docx, reference

You can see how 0 is inserted before 1..9, but not before 10.

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

Then I found that footnote numbering needs explicit handling, so added support for padding in that case as well:

Finally I had a little bit of remaining time, so I extended support for the recently added Chicago numbering:

Future work

Padding up to 3, 4 and 5 characters would be possible to do, but it’s DOCX-only, and uses a different markup, planned to be done later.

All this is available in master (towards LibreOffice 7.0), so you can grab a daily build and try it out right now. :-)


Semi-transparent text in Writer

Estimated read time: 1 minutes

The problem

Last year I posted about work to have semi-transparent rendering of not only shape fill and shape borders, but also shape text in Draw. Now the same semi-transparent text feature is available in Writer as well. This improves compatibility with Word, which supports the same feature in its DOCX format. You can access the new option in the Format → Character dialog.

Result

Here is how the new, old and reference rendering looks like:

https://lh3.googleusercontent.com/oifzSVcdmKhomkQQKy4CNnPmamHtoo9CwRsbg9_ekbeK9Ov_4dFrzrJrYmDLHZNm-IvsoYNy8YfSs5kp4yEA42jybRO-8P-YKI8fYRu5ColRbzFHQBotP4MvkjanZG7JX9vP8Mcnnw=w640
Figure 1. Semi-transparent text in Writer, new rendering
https://lh3.googleusercontent.com/RxtyxxIdrW14TtN30cf37e7RNHwnQpxlX-zhjhpWrggjStEERXvUnH7eDv8acM_8DcySNpnvpz5yWdwO12_cmQ6ZyCo4-fpIOdd3x9Q8SAXxAwuyMhfmjzhvS9VDBps8tQX-xB70RA=w640
Figure 2. Semi-transparent text in Writer, old rendering
https://lh3.googleusercontent.com/6rkCyXnzfiVN96D1h8PiKSIva1ydRFQXzUbXbbLC-9plXOUJnMRHZT2ba4eKt7W1wqfL3vscVgE1-QB5ztbp2uqSmguOALV8wyZDnCF4LPlyHSbVEm5atwZvf29w3PzRmjy11aQahA=w640
Figure 3. Semi-transparent text in Writer, reference rendering

Want to start using this?

You can get a snapshot / demo of Collabora Office and try it out yourself right now: try unstable snapshot. Collabora is a major contributor to LibreOffice and all of this work will be available in TDF’s next release too (7.0).


Improved rotated text handling in Writer's table rows with automatic height

Estimated read time: 2 minutes

Writer now has better support for rotated text in tables containing rows with automatic height. This post also presents two related fixes.

First, thanks Otevřená města who made this work by Collabora possible.

Before diving into improved rotated text handling, first a continuous section break import problem (tdf#128605) was fixed: this was a case when we created a new page style, but only a new section was intended. Here is how the fix looks:

https://lh3.googleusercontent.com/ycsIqjpdm5t2n9FQQhKBbWobpsX2cQ0s-ugLn970XwuGafzL79HzNVly6dYUpLMhTQmZq8Aa36kaGIfWfk-MzYmuSr92zhRUxFk1aNqwDOnTy1cyyrRzCguuvp-Wd3LD8XXzo_Aurg=w640
Figure 1. Importing continuous section break, fixed
https://lh3.googleusercontent.com/jLUVDTY3Z6-IWVCmSfia7ue_aSpXSG7YJK2WqhRCfJkdTgA3cVFRh8TiYZwKRut7vvC0yFkdGBzl9Wpv2auZpg6d84nmDI1gVHBZPmWsf_YA-5qD-SF8Uf2lBG7NOu9RcidR1bQ0ng=w640
Figure 2. Importing continuous section break, original
https://lh3.googleusercontent.com/izfhxSHtYg_QmeJdIY_NnX5uiaRsmDHQoPlAsofQSaLJERNzVq_gkOMShR-fzckvAd6E5D-ZEMbr41Db2PEMeUZA8gL-oqJsvf_3PytuxJhL95wz4Fsh-2JakWefx4Tes2MoHlFWWw=w640
Figure 3. Importing continuous section break, reference

What you can see is that the continuous section break used to result in an unwanted page break, and this is gone now.

Regarding the actual rotated text handling (tdf#128611), there were two problems there:

  • There was a missing flip handling for line shapes

  • Poor layout of rotated text in table cells with automatic height

Here is how the fix looks like:

https://lh3.googleusercontent.com/GFCNQDcvXsN2w1ADVo10H16FUOYB8i6jBTrPad0r6qa8nt8PmDBDD1oiDfG9Zs9_3eVqdyB-O-u6oWIBAujcyso2utvnDpdE4Bs2PykeJkbh0vSYMZDSIKsjv7vI06j9HUCru2Z19w=w640
Figure 4. Rotated text in table cells with auto height, fixed (both flip of line and text layout)
https://lh3.googleusercontent.com/IqsWjKbTD03_wnvUMUe_QK1pqdTfZKizoNEHRQDQuvpw_O8mrEQ8AgNk_2qbP49QUpezknqHDxnhn0eYDpfZL833dXaClRPD1e4_wxuTj5mTRTeEgioBCX0djcWa5vNSRdPmnalphA=w640
Figure 5. Rotated text in table cells with auto height, fixed (only flip of line so far)
https://lh3.googleusercontent.com/2Tkkj7oz9Bm9ckPs5lTGwAGBRokEJ0MWxfqrbqu6afp6Xm1I77zft8riW-kTxKo4kJsO6bwMtaZb0XNToFssEc1kkZuzm0qk0H4eLU-xk8DOd-e5eVMtNR6cYD_1FRDWbCIYok1oJg=w640
Figure 6. Rotated text in table cells with auto height, original
https://lh3.googleusercontent.com/m3X4dGiUTsFBnVwQhiEpcAQYGAJ_8vbKN93jivrcsKcCvjaornrk0upCvsTmck1e39XISyuYNc47BF1tuyrskoWLuMhpegtbyPh1KjBD7_wD-oLueaaLbjYnrgReSRkS5krvK1y4LQ=w640
Figure 7. Rotated text in table cells with auto height, reference

What you can see is that the line clearing the table cell had a vertical flip, which was lost on import. Also, the rotated text in the "row heading" cells was broken into multiple columns. Both are fixed now.

All this is available in LibreOffice master (towards 6.4), so you can try it out right now, if interested.


Semi-transparent text in Draw/Impress

Estimated read time: 1 minutes

Draw/Impress now has support for semi-transparent shape text, next to the existing transparency support in the context of shape fill colors and shape border colors.

First, thanks Vector who made this work by Collabora possible.

Here is how it looks:

https://lh3.googleusercontent.com/FJ55-BJ_Mc75TiyrPYuvtOscHOqFp81sEI4SfJvybPzaXG5Y2n4mIoLRzkXydEEmtEf--l9s_h-L4CyYjuGpTyOngOTi8YAzIFp8bQBEn0k2DWsRzJHLdfttf74wTbdPgZUzgSnOYQ=w640
Figure 1. Semi-transparent text in Draw

What you can see is that next to the existing character color, now you can also set a transparency percentage to decide if the text should be entirely transparent, entirely opaque or something between the two.

The primary focus was Draw in this case, but this also helps PPTX support, as the importer/exporter now handles this for Impress documents as well.

All this is available in LibreOffice master (towards 6.5), so you can try it out right now, if interested.


Better math import from PPTX into Impress

Estimated read time: 1 minutes

Impress now has a much improved math handling in its importer from PPTX, eliminating annoying duplicated objects you had to delete after import, manually.

First, thanks TU Dresden who made this work by Collabora possible.

Here is how it looks:

https://lh3.googleusercontent.com/zI1fDb7tfl0a-6e1JljnBuCz67cGBSpx3s_tMViW_xWpTjy0FrsLGws-VAXWcdQhmSwXddr9wjADs5UvhNu_sNjETT7VfMJB8pdQ4PxPpHliCVbuMOx67Wwrd6brfE-eJtWIb2K36A=w640
Figure 1. Impress, new math import from PPTX
https://lh3.googleusercontent.com/rpC9KOUaadEoYKekczLTZakB98SBwqbKGqmwf_VLY6D-8OpBLh9Lpxi_RDl6CMQHJKqsz0NnxgTN8kn63CB9fGmP6AWUKIqK0huvjoRCxvoh6dtd0BMRXclsWlaKr3jbdzb1TOJ1LQ=w640
Figure 2. Reference rendering
https://lh3.googleusercontent.com/hUBhfLLFPZFDa50EMPEQxl2kih91oKIfQFBxNK7F9uWGexGbUKnV1FMQZgvmj4EctmCwlxlYK56hPSX0RZS_MpOAKZZagmfOALZ3LRrvBgoOGAx9dsM1N3dp9bGvPU7c0WVvROu8iQ=w640
Figure 3. Impress, old math import from PPTX

What you can see is that the in the old case we managed to read both the actual math object and its replacement image from PPTX, which caused visible duplication due to working transparency handling. The new way just imports the math objects, and ignores the replacement graphic.

This new way (handling of the OOXML a14 feature flag) is enabled by default, except for Calc documents, where more works is needed before it can be enabled.

All this is available in LibreOffice master (towards 6.4), so you can try it out right now, if interested.


Continuous endnotes in Writer

Estimated read time: 1 minutes

Writer now has a new "continuous endnotes" compatibility setting in its layout, allowing rendering endnotes in a way which is closer to what Word users expect.

First, thanks TU Dresden who made this work by Collabora possible.

Here is how it looks:

https://lh3.googleusercontent.com/g4kmuKduOm-Xc5sHH5oBx9y-U8S6hK5pgamrLxG-5fM9XCRJwMJFEPKxWXrG6IzEQLVpHdxCHI0c45EjDax02SpDbIzyQjZvUd-gsvpTWlkgZ0p3Y5-FDXARIPggF0KyIwG1AFwoiQ=w640
Figure 1. Writer, new ContinuousEndnodes layout flag enabled
https://lh3.googleusercontent.com/dlUGc11qUKVvvkKXh5mhj9BlEw4bLxgKxW_t3pNAAu2rnuWuIrFtWdlKk-8nadbSur8CaDe-CIUNJiSJlQSTvA22Q89TkY-uRsdJH3EKX6RcyUJsr-W5YqJrVqaM4KgXAIDPxPXPvg=w640
Figure 2. Reference rendering
https://lh3.googleusercontent.com/odkN2eqFxYthY7qhxHwStIlodTZJmcUa5wzh6p74PWPT6jKtsAmAvZyNzTjwff_CrDm5AtTcdAq_Rw2QyMNQN1Xr_ypIYL_cEZ3g1DRJof9em6acQ1fxrNQWsx_LxUmBhmu4TkTmPw=w640
Figure 3. Writer, old separate endnote page layout

What you can see is that endnotes unconditionally start after the end of the document content in Word, while endnotes are unconditionally on separate endnote pages in Writer. The new ContinuousEndnotes layout compatibility flag in Writer allows rendering endnotes the Word way.

This new flag is enabled by default for DOC files, disabled otherwise.

All this is available in LibreOffice master (towards 6.4), so you can try it out right now, if interested.

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.