Field Alignment on Exported PDF or CSV Reports

[jmcelhin]

I setup a search query which will create a report on a daily basis. The report will be emailed as a PDF or CSV file. One of the columns in the report is Username. In my organization we have usernames that are all numeric as well as non-numeric usernames. On the report, the non-numeric usernames get aligned to the left while the numeric usernames get aligned to the right. This makes the report difficult to read.

After doing a little research I discovered that this is by design. The PDF exporter is designed to align text fields to the left and numeric fields to the right. Is there a way to change this default behavior?

I've taken a stab at this with no success. My first thought was to use the Eval - ToString() function as follows:

Eval User=ToString(User)

My thought was this would convert the numeric usernames to a string and they would therefore be left aligned in the report. To my dismay, the numeric usernames were still aligned to the right.

I created another field in my report to verify the type of the field (numeric, string, etc...) by using this command:

Eval Type=typeof(user)

This command was placed directly after the ToString() command. I discovered that even after running the ToString() command, the field was still being identified as a "Number". I believe this is why the field is still being right aligned on my report. I have no idea why the ToString() command is not converting the field to a string.

I must be doing something wrong. Is there a way to get numeric and non-numeric fields both left aligned on an exported PDF or CSV report?

Thanks!
Joe

[martin_mueller]

As a stab in the dark, try this mildly hacky thing:

... | eval User = " ".User

That'll prepend a space to the User field, forcing it into a string... which should normalize your alignment, assuming there's no sneaky optimizations hidden anywhere.

[martin_mueller]

That sounds as if something applied a trim() to all fields and then the default string-to-number conversion kicked in... hmm. You could try prepending an underscore just to test the principle:

... | eval User = "_".User

If this works we'll have to find another invisible character that doesn't get trimmed.

[jmcelhin]

Yeah, that works. Do you know of any other invisible characters besides a space? I tried a couple different ASCII characters I found online (0160, 255) but they pretty much equate to a space anyway and were trimmed off by the PDF exporter. I may just have to live with prepending a character to the usernames.

[iKate]

I had the same issue and solved it with zero-width space code (& #8203;)

| eval User = "& #8203;".User

Use it without space in code

[jmcelhin]

Hey Martin,

Thanks for the help. I gave this a try this morning and it did successfully convert the numeric usernames to a string. I verified this with the eval typeof() function. Unfortunately, when I exported the report to a CSV or a PDF file the numeric fields were still aligned to the right. There must be some code in the export utility that's superseding the conversion in the search.

It's very odd behavior. I'm sure there's a valid reason for it but it'd sure be nice to have the option to align the fields either way.

I'm beginning to wonder if there's any way around it.