HTML Overview for Proofreading

HTML layouts are divided into sections, and created in tables separating the images & content sections. The copy within the body of the is entered as live text. Building an

 Live text is webpage copy that has been entered as HTML code rather than displayed as part of an image file.  The key benefit of HTML live text over non-HTML alternatives is that content can more easily be customized or reformatted for different browsing devices, it is in a web safe font, able to be seen even if images are turned off & read by spam filters to identify if it’s a legitimate , it can also be picked up by screen readers & assistive technologies.  Live text moves/adjusts according to where it’s being viewed, & there is minimal control over where it may break or cause widowed words, therefore re-ragging or running back words is not always a request we can accommodate. Live HTML Text

Preview  An is one scrolling page viewed in an client’s preview window  There are no pages or page numbers  This is the preview window in which the proofs are printed to file & saved as a PDF for the client to view

 A live does not have pages, just one scrolling preview

Creating a proof of the

Header & footer envelope information  This is the envelope information associated with the & is not part of the actual design  “To” and “Sent” information is due to the timestamp of when the proof was made & is not associated with the itself  Spaces in the header & footer are due to the PDF print output, not the display of the

 Symbols & special characters are HTML elements  The envelope information including the subject line is entered in the StrongMail delivery system as hard text & is not a HTML element  Using symbols increases the risk of an getting marked as Spam Subject lines & special characters

 The hedge language & layout for RWC templates is legally approved, & we do not make changes.  Outdated hedges on markups are automatically updated to the most recent version & no variations are made other than link color changes to match custom branded templates. Hedge

 With the release of Outlook 2007 & 2010, Microsoft switched to Microsoft Office Word as a rendering engine for both reading and composing s in Outlook from its previous versions that used Internet Explorer to view s.  Microsoft’s decision to avoid using a browser to render HTML ignores standards-based design & allows less control for designers over how HTML s are rendered, & Adobe Acrobat proofs created from these s do not accurately display the way the is actually viewed in the preview pane. Outlook 2010 Rendering

Outlook 2010 does not support:  Animated Gifs, JavaScript & Flash  Background images & shadowed edges  Forms  Wrapped text  Justified text  Borders on images  Middle text alignment alongside images  Font rendering  CSS Support  CSS positioning & image float  width properties with background colors (i.e.: 100% background table width with background color)  Padding values & failure of the tops of cells to line up properly resulting in cut off background colors. i.e.: white lines  Formatting: Word applies its own print based formatting that applies automatic page breaks and gaps in the layout of long s with a lot of content  Outlook 2010 adds a one pixel gap under (or over) every image inside a table cell  Ignores image resizing  Automatic letter spacing

Questions?