Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Should css styling not appearing in exported documents

    SmartClient version v10.1p_2016-11-11/PowerEdition deployment ( built 2016-11-11)


    Im exporting to PDF, I have a VLayout where setBackgroundColor("black") is called. The page is rendered as expected with the background color appearing black. When the component is exported toPDF the background color in the PDF is white which is the default. ( the setBackgroundColor seems to have no affect on the PDF rendering )

    If I remove the setBackgroundColor and a add a styleName for an associated style I created to set the background to black the PDF export is styled as expected with the black background.

    I haven't investigated every place I set styling in the code ( similar to setBackgroundColor, setColWidth, etc ) but it looks to me like none of these are being applied to the exported PDF.

    Is this the expected behavior or am I missing something

    Thanks


    #2
    Many components have both a normal style and a print style. We can't assume that something like a backgroundColor setting is intended to both be used for the component's normal appearance and it's printed appearance.

    It may seem strange that we would do this for something like a VLayout, which has no alternate printed appearance, but it has to be a general rule or we would end up with a confusing list of exceptions, especially when you consider that components that do have an alternate print appearance are subclasses of Layouts (eg ListGrid).

    Comment


      #3

      So are you saying in-line css/styling set via the gwt api ( like setBackgroundColor ) should not be expected to be applied to export ( in my case PDF export ).

      So for the VLayout I see no methods like setPrintStlyeStyleName("printStyle") or setPrintStyleBackgroundColor( "black") or something. It there a mechanism to specify print style vs "normal appearance" using gwt api or other mechanism for all components.

      Thanks

      Comment


        #4
        Also seeing some older posts (2009) claiming iText 2.1.7 doesn't support inline CSS. Just curious which versions of iText you are using

        Comment


          #5
          Hi wwarriner,

          I'm also just looking at the PDF export sample. JavaModuleDependencies-docs mentions some iText details.

          Best regards
          Blama

          Comment


            #6
            thx Blama

            Comment


              #7
              so isomorphic

              are you saying in-line css/styling set via the gwt api ( like setBackgroundColor ) should not be expected to be applied to export ( in my case PDF export ).

              So for the VLayout I see no methods like setPrintStlyeStyleName("printStyle") or setPrintStyleBackgroundColor( "black") or something. It there a mechanism to specify print style vs "normal appearance" using gwt api or other mechanism for all components.

              For example Im trying to export a timeLine to PDF. Im setting the lane height using the lane.setHeight( ) method. Renders fine in browser but this styling ( setting of size ) is lost on export. Its not clear to me how I would add this styling for printing ( export to PDF ) of for that matter how I would set lane height via css since there is no set style method on a lane ?

              Thanks

              Comment


                #8
                1) yes, that's largely true - if you want styling to appear in prints and exports, apply them via styleName. See the printing overview in the docs.

                2) in fact, there's an attribute, Canvas.printStyleName, which is used in some internal cases - we've exposed that and it's getter in 12.1. In earlier builds, you can just setStyleName(), because getPrintStyleName() returns this.printStyleName || this.styleName.

                3) In the specific case of Timelines, lane-heights should indeed have been exported to the PDF, since eventCanvases are absolutely positioned and sized - as you noted, this was true in printPreview and printed output, but not in PDF exports. We've fixed that, and made several other print/export improvements for Timelines, for builds dated February 20 and later.

                Comment

                Working...
                X