We insert client logos, barcodes, QR codes in the client table, as PDF in containers, and relate to them via related containers on letters, recipes etc - only print layouts. Screen real estate is too precious to have logos displayed on input / work layouts.
Here is an example of our client settings:
A frequently used method is to use a start up script to load global fields/variables from such a table. The globals can be placed on any layout in your file without setting up a relationship.
A slitely different way ro do it is to have a global table, that is a table with only global fields. This table holds information that can be used everywhere. The advantage is that you don't need a reference to a gobal table to display its fields.
in our solution you might have 60 clients, each with their logo.
At the reception desk people log in with any client, then have to print a letter from another client.
Globals won't cut it.
True. But the client may need the "branding" everywhere. That's when I suggest small icon. That is usually enough.
I've got a few clients that must have a "watermark" (almost transparent) on everything, should a layout be printed (yes, even screenshots!)
Sent from miPhone
can be solved with a sticker on the top part of the screen
You can't beat hardware with software lol
Only if you use a camera for the 'screenshot'. LOL
Sent from miPhone
Siplus said "globals won't cut it".
You are correct if you need to access data for different user, but they work just fine for data that needs to be globally displayed for the current user--such as the current user's company name, address or logo.
"The advantage is that you don't need a reference to a gobal table to display its fields."
Not quite. Any global FIELD, regardless of the table, is accessible from any layout in the file. Global variables may also be used.
But global fields/variables need corresponding non-global fields used to initialize the globals when the file opens. This makes the info or logo globally accessible while still enabling you to update this info by editing the corresponding non-global field.
Of course you can use Cartesian joins to reference the data in the non-globals and then not need the globals but this can require more table occurrences in your relationship graph so it's a trade off as to which to use in a given solution.
In our solution we have 15692 fields, out of which 3711 are globals. Guess we know how and when to use them.
But global fields/variables need corresponding non-global fields used to initialize the globals when the file opens.
for your company logo:
I just started to change all layouts by using a Button Bar with 1 Segment and have my Logo in the Button Bar Icons library at hand.
For customers logo, I use a container field with the script step 'Insert Picture'.
Hey guys, thanks a lot for your responses. Gonna go with the the global container field in a global table (which I already have). Using a 5kb .png file should keep page loading times down I guess.
You will use logos for different purposes: GUI AND Printing.
Graphics for GUI only should meet requirements of Retina displays of today, graphics for printing should meet requirements of a printer of course.
My advise: Testing, testing, testing …
When I only have one organization's logo(s) to worry about, I opt for SVG button icons.
For more, container fields are the way to go. Other folks have already posted on approaches to this. Benjamin mentioned images for specific display purposes: on-screen vs. print, but also full vs. compact, B&W vs. color, horizontal vs. vertical vs. square, light-on-dark vs. dark-on-light, etc. In particular, it's tempting to suggest that the answer is SVG for everything, or at least vector for everything. This is not always the case (though if you're generating variations yourself, it's definitely wise to start with a vector version as the authoritative source).
Container fields don't display SVG, and EPS is deprecated. PDF is the only thing I can think of off the top of my head that will show vector data in a container field consistently.
Web Viewers are a tempting option for displaying SVGs, but be careful printing them. The last time I tested, an SVG in a Web Viewer printed on Windows only printed at on-screen resolution, not the resolution of the printer. It's been a while since I tested this, though. Can anyone speak to whether or not this is still the case?
Vector formats don't always make smaller files. The flat design style that's in season right now is very compressible in PNG. Container fields render PNGs just fine, and you can also set them as a background fill on layout objects, which means they can be shared (and modified!) solution-wide via theme styles.