Looker 6.6 PDF Visualization Errors


(Baha) #22

Hi @izzy , we still have not deployed it and holding it off until the updated fix is out.

Do you think we will see an update this week?

(Ian) #23

+1 for the above

(Izzy) #24

I’m in contact with the engineers and PM working on this. I’m hopeful that we will see an updated fix this week, since progress is being made, but I can’t give any firm promises.

In the spirit of mostly-full-disclosure, we have not yet 100% identified a fix for all of these issues. We have a fix for most of them, but it causes problems of its own that we’re working on ironing out. So in lieu of a promise, here’s a roll call to make sure everyone’s informed of the current status to the best of my ability.

@IanT, it looks like you’re primarily concerned about wide tables being cut off on the right side of the exports, is that correct? If that’s correct, it’d be super helpful to hear what your desired functionality would be— A very small/scaled table that fits on the screen? A wrapped table? Any input would help guide our changes. If that’s not the issue, definitely let me know what is.

@dgold, the gaps in between tiles and subsequent mis-alignment of tiles that you were seeing is one of the issues we’ve identified as key to getting this all wrapped up— Our initial fix did not fully resolve the problem, but we have another in the works and are just making sure that it plays nicely with all of our other features before rolling it out.

@basahin, looks like the single value visualization comparison smushing is your poison. I actually haven’t been able to personally reproduce this one, but I’m reasonably certain it’s related to the gaps between tiles and the strange tile cutoffs, since all of those seem to relate almost exclusively to single value visualizations and their sizing. That means it’ll be wrapped up in the same fix for tile gaps, which, like I mentioned above, is prioritized + in progress. I’m making sure that it gets visibility by itself, though.

@simon_onfido, thanks for coming clean about those font sizes :wink:. The issue you mentioned still existing is, as you guessed, related to/the same as Danny’s, and will be addressed by the same fix.

Thanks for all your patience, and I’m sorry that this is such a complicated one. Thanks also for giving us lots of useful feedback to pass along & help drive this. In the future, we’ll work on improving rendering tests before a release as we know exports have a much wider reach and want our customers to be rock solid in the field.

Definitely keep the questions coming, and I’ll do my best to keep the answers flowing as well.

(Ian) #25

Yes that’s correct, wide tables are just getting cut off, whats weird is the image object is actually the correct width but the image from a certain point is just blank.
Before 6.6 these wide tables were still put in a email and the user had to scroll (or have a wide enough res to show the whole table).
That’s what we had before and wish to return to.
I suggested over chat about this subject last week to re-release the legacy rendering option which was remove for this version until this is fully fixed.

(Izzy) #26

Thanks for confirming that + clarifying the behavior, I’ll carry it onwards.

(Nicolai Jorgensen) #27

Hi Izzy

I’m a colleague of Ian’s. Short answer is “yes, probably”. Cropping is currently our main pain on the Looker schedule delivery side.

One of our delivery specific use cases, is single column layout via Email.
We trigger a lot of daily deliveries per schedule or via the API, and these enable us to push DWH/Looker content to people who need that data for one reason or the other.

Prior to the upgrade this was possible, even with wide tables, and content was easily readable on both small and big screen (mobile, laptops, ext monitors…). Ideally we would like to easily control mobile message-reformatting and styles, but the deliveries did the job.

After upgrade:
Looker now crops such single column layouts at a visible width of 800 pixels, which is way too narrow in my opinion. Why the need to fit a size in this layout type at all? Funny enough the image size is actually wider than the rendered area, and the righter “cropped” part is white (or whatever your dashboard bg color may be). So if we could just get last part filled.

To your suggestions, I don’t see why you’d have to scale or wrap the table, since we don’t have to fit a certain width in email single column layout. I’d suggest looking at how it worked for that layout type in previous release, and render the table data like that, with a “fixed” style/font size with the smallest column width possible, wrapping headers and string values if needed.

No scaling of the image to fit 800 px, and no cropping of content. Cropping is the worst of the two in my opinion though .

Other considerations:

  • Identical content is rendered very differently in terms of height between pdf and email, even when both have same option ticket: single column layout.
  • Choosing “Show title” = Off is not respected, and it will insert Title as text above the tile in the delivery.
  • Email SUBJECT is always repeated in top of email. While using API /scheduled_plans/run_once the “name”: “string” still applies to both subject and email intro. Any way to control this would be nice.
  • If a fixed width layout continues to be how it works, some kind of visible guidance in Looker would be nice

I’d be happy to provide more examples than already in the issue report if need.

Thanks for looking into this.


(Izzy) #28

Thanks for the excellent detail, context, and the suggestions on how to approach a fix. All three of those are extremely useful, and I’ll get this in front of those working on it.

There’s a lot in there, so I’m going to focus on the 800px cut off for now, but your other considerations are all greatly appreciated and understood— I will look into them as well.

I’ll be keeping this thread updated and as always, keep firing away with any questions.

(Ian) #29

I have just notice that the legacy rendering feature is still available until 6.10 (which says for some reason is in about 18 days, 6.8 i would assume is actually in that time). I thought I had read that it was gone in 6.6 but I never took a look in the legacy features section in admin.
I am thinking about turning this back on and testing, unfortunately this is bad timing for us as our dev instance is broken!

(Izzy) #30

Good to know!

I suppose that is what dev instances are for.

Daily update: I passed along your suggestions @nicolaipj, and I know our engineers also went back to older versions to look at how we did this kind of rendering previously. We have identified a working fix for the column cut-off issue, and are hoping to finalize it very soon. More to come shortly.

(Izzy) #31

It’s been a couple of days— Our latest fix is complete and is just going through testing. Once it’s out, I’ll let you all know and you can download the new jar file.

Have a nice weekend! Let me know if there’s any questions, and I’ll update here as soon as I know more.


New security update 6.6.21 has this bug fixed already or should we wait until new version comes out?

(Ian) #33

Is there an update on this today please?

(Baha) #34

+1 It would be great to get an update on this, it has been nearly a month now and would be great to arrive at the full resolution

(Izzy) #35

I have my fingers crossed that it will be available soon, but there’s no update yet— We’re still running tests. I’m working with the engineers on this one and I’ll know as soon as it’s available. Thanks for your patience, and know that I’ll be filling you in the second I have news.

(Yo) #36

We have recently upgraded to the latest version of Looker 6.6.17 and seeing this error for our scheduled reports for most of the users “format format wysiwyg_pdf invalid – valid formats for Dashboard sent as ‘email’ are [:csv_zip] (code: invalid)”

Just want to confirm that this is the related to the same mentioned in this thread. What you guys recommend to do here, wait for update or turn on the Legacy feature “Legacy rendering on” until we get a fix for this ?

(Ian) #37

Hi Izzy, this is getting a bit desperate for us. Can you please spend a small amount of time looking into if 6.6 has directory and/or db schema changes from 6.4. I am looking at putting the old jar back. I will have a test as well by turning on the legacy rendering.

(Izzy) #38

Definitely, I’ll verify whether 6.4 & 6.6’s schema are compatible in the morning when those in the know wake up.

In the meantime, let me know if legacy rendering works, and I’m also quite confident that we will have a working jar for you tomorrow as all tests on the fix have passed.

(Izzy) #39

@IanT, there were changes to the schema between 6.4 and 6.6 that make a rollback a bad option (There almost always will be problems between versions). I definitely can’t recommend replacing the jar.

I’m working for availability of the fix today. Would you be open to updating to a version of 6.8 that would contain the fix, or would you prefer to stay on 6.6 and patch that?

I also took a few minutes to run some tests and it looks like Legacy Rendering is working well (ie: not cutting off columns) so I definitely recommend turning that on and proceeding with your schedules for now.

(Ian) #40

Yes I turned this on today in dev (got it working after a while!) and it was back to the good old days, I will turn this on in production and can test 6.6 with the hopeful fixes. In light of this issue from now on we will be upgrading versions with a longer lag time so we can fully test versions (6.8) and see issues from other customers before we encounter them ourselves :wink:

(Izzy) #41

Noted, I’ll take that to answer my question— in favor of a patch for 6.6 and not just an updated 6.8. Thanks for letting me know, I’ll run that back and get it built.