Sunday, July 23, 2017

How to Quickly Fix Skin Tone with Too Much Shadow in Photoshop

When you’re in the printing business it’s necessary to be quick at editing graphics supplied by clients in order to keep up with their delivery time requirements. My best friend Rommel Hachero is a co-owner of Bimbox Advertising and is always on the forefront of editing such graphics. As an expert in Photoshop, Rommel showed me quite an easy way of editing photos that have low-quality skin tones or too much shadow.

Here are the procedures he told me to do. Please note that these procedures apply to CMYK mode files.

  1. Open the subject photo. As we can see in the sample, the skin tone looks somewhat okay but there seems to be too much shadow.
Shadow covered face

There’s too much shadow covering the skin areas.

  1. Duplicate the background photo by pressing Ctrl+j in PC. Create a blank layer that will be used as the color for the skin. You can name this layer if you want. I named mine skin color adjustment layer.
Procedure 2

You don’t actually need to duplicate the background layer, you can directly create the skin color adjustment layer if you wish. I just duplicate the background just in case I need to edit something to it.

  1. On the skin color adjustment layer, set Layer > Layer Mask > Hide All.
Procedure 3

Create Layer Mask.

  1. Using the eyedropper tool select a skin tone color in the photo that is just right for you. My friend suggested the skin tone color should have zero Cyan and zero Black. Fill the skin color adjustment layer with this skin tone.
Procedure 4

Fill Layer Mask with skin tone color.

  1. Set skin color adjustment layer to a blending mode of Screen and an opacity from 5%‒50%. I used 20%, but we can adjust this later if we like. Select the Layer Mask thumbnail then using Brush, start erasing the area that you want to fix the skin tone. Or you can use Path tool and Load path as selection, set a small amount of feather (1 px will do), then delete.
Procedure 5

Set blending mode to Screen, adjust opacity, then delete Layer Mask using either Brush or the Path tool.

  1. After noticing that the subject looked like a vampire due to the pale color, I adjusted the opacity of the Mask layer to 7%.
Procedure 6

Adjust opacity if necessary.

I’m not an expert at photo editing/manipulation yet. So the output of this procedure is not well done as you can see below.


Original (left) and edited (right) versions of the photo with too much shadow.

But this technique that my friend shared to me is a welcome procedure in Photography post processing.

Do you have your own way of editing skin tones with too much shadow using Photoshop? Feel free to share them too in the comments. Thanks.

Please do visit my Photography website at

Wednesday, May 28, 2014

An EPUB Validation Tool That Will Trample All Others

As a member of a current group of EPUB Specialists in CircleGraphics Philippines, I’ve been able to use and compare a few EPUB checkers, most of which are of course libre. Flightcrew was excellent in its time, but the developers seemed to lack conviction and it eventually stopped evolving. We still use Flightcrew though, because it could find errors that more recent EPUB checkers cannot. Another EPUB checker we use is the drag and drop pagina EPUB-Checker which is based on the open-source epubcheck tools. Pagina EPUB-Checker also finds EPUB errors that Flightcrew doesn’t catch. So, to “minimize” any untoward incidents with the submission of our EPUBs, we use both Flightcrew and pagina EPUB-Checker.

The process of validating an EPUB is easy. With time and experience, you’ll be able to resolve error reports and warnings that might occur. And once you get a glimpse of the words “No errors found”, you can finally put your worries to rest and sleep comfortably. Right?

Wrong! EPUB submission is just the beginning of a nightmare. You see, EPUB is the promise of a cross-platform ebook. A digital format that can be read in any ereader. In a sense, it’s true, but the underlying problem here is that each ereader device manufacturer has their own standards for creating EPUBs that will work properly in their system. Even though our EPUB group has a list of these EPUB publishing standards which we tediously check before we submit an EPUB, worries still come to mind as to whether the EPUBs will pass publishers’ EPUB validators. Some EPUBs return back and, along with the error reports that come with it, we’re able to learn a thing or two about requirements that different publishers demand.

It’s vexing though when all we have is a theory that, the EPUBs that didn’t come back passed the publishers’ validators. We have a blind spot during these times, and we wonder if these publishers could lend us their EPUB checkers just so we could rest easy knowing that our EPUBs would make it to the ebook shelves. But that’s shooting the moon.

eBook Architects to the Rescue

I’ve come across an article in The Digital Reader by Nate Hoffelder mentioning FlightDeck, an EPUB validation tool created by the team behind eBook Architects. After a few minutes of checking this out, I was completely hooked. Right now, it’s in free beta, so I suggest to the reader to take the opportunity to test this validator as soon as possible. It simply overwhelms. Well, for me it does.

If you visit the FlightDeck website, you will be asked to sign up for the free beta. After signing up, you will have the option to upload your EPUB. FlightDeck will then validate the EPUB and create reports. It also has a Handbook of links to different EPUB resources (which probably you would already have all, if you have been doing EPUBs for the last four years).

What is striking of all these reports though is the one that shows where or to what publishers the EPUB will pass. As of currently, FlightDeck can check whether the EPUB will pass for the iBookstore, Nook Store, Google Books, KoboBooks, and NetGalley (Amazon soon to come).

Reports that FlightDeck generates are the following:


Shows the following reports…

External Links shows all of the external links that are inside the EPUB, and gives the option to show the location of each link.

Embedded Fonts lists the fonts embedded in the EPUB. If no fonts are embedded it reports “This eBook uses only the default fonts from the reader's device.”

Text characteristics gives a detailed report on the number of characters, words, lists, tables, and images in the EPUB (I just wonder how the number of images fell in the category of Text characteristics).

File Sizes by Type shows the total file sizes of HTMLs, images, and CSSes in the EPUB.

Largest Files shows only the largest files in the EPUB.

Image Dimensions shows the dimensions of the largest images in the EPUB. If there’s only one image, it shows that image’s dimensions.

“Start Reading” Location shows where the EPUB will begin when initially opened. This is in the <guide> section of an EPUB and will not pass Google Books if not specified.

Header Levels shows the number of headers you have from <h1> to <h6>.

Table of Contents shows the Table of Contents of the EPUB.

The Metadata portion…

Lets you manipulate the metadata of the EPUB. Comes very handy for those moments when the only problem that needs to be resolved is only metadata deep.

Validation messages…

Show reports like the usual Flightcrew and pagina EPUB-Checker. I haven’t delved much deeper into this though, and don’t know yet whether it misses some errors that Flightcrew or pagina will be able to find.

Best Practices gives…

Recommendations to improve the EPUB. This is an excellent tool to help an EPUB developer learn what needs to be added to an EPUB to make it pass most publisher validators.

And the Best of the Best, the Retailer Grid

Shows where or to what publishers the EPUB will pass. This is a heaven sent option considering we have worrisome days and sleepless nights thinking whether or not the EPUBs will pass iBookstore or Nook Store. Thank you so very much eBook Architects.

Well now, no more sleepless nights. I guess…

Test FlightDeck while it’s in beta. It’s really worth a try.

Friday, June 14, 2013

Font Units in EPUB

Doubtless, this subject has probably been answered in many EPUB discussions. Still, the question as to what font unit of measurement to use in creating an EPUB is generally unanswered. Unlike in print, the variety of font units in EPUB files is sophisticated. In my opinion, the best way to determine what font unit to use in EPUB is to answer WHY we use it.

In print, font unit problem is not an issue. Units such as inches (in), centimeters (cm), points (pt), and picas (p) are absolute values. Points are the most common in print when setting font sizes and has probably become the standard through many years.

Absolute values are units that are independent from any other relationships. For example, a 12 points font size will always be 12 points.

The problem of font size in EPUBs is due to difference in size and resolution of various screens. Screen fonts use relative values such as pixels (px), ems (em), and percent (%). I think, as of this writing, no standard for font unit in EPUB has been established YET.

Relative values are units dependent from/to a relationship. If a font size for example is in pixels, it is relative (or dependent) to screen resolution. An em is relative to the default font size provided by a browser or ereader (usually 12pt = 16px in browsers).

EPUB is quite new and like its print counterpart, it’ll take time before a standard can be set. EPUBs whether we like or not, are web pages inside a .zip file and therefore can have quite similarly the rules of typography in web design.

Ems versus Pixels

An article in under web design entitled Using Points, Pixels, Ems, or Percentages for CSS Fonts tackles the use of relative units in Cascading Style Sheets (CSS). The concepts presented by the author Jennifer Kyrnin can be applied to EPUB development.

Jennifer’s article focused on “ems” and “pixels” and explained when to use one over the other. She stated two rules of thumb that concerned “accessibility” versus “control”.


If accessibility is your biggest concern, then you should use ems. Ems are sized so that the font size is relative to the parent element. In the case of most Web pages, this is the body element - and so the font is sized relative to the standard size of the browser.

Using ems as your font size measurement ensures that your pages will be accessible to most browsers and platforms. Plus, if your readers choose to change the default font size on the fly, your page will scale to that new size. …


If control over the look of your Web page is your biggest concern, then you should use pixels. Pixels are the standard unit of measure for screens and monitors, and fonts will be more precisely the size you want on the screen.

Pixels are the measure of resolution, and the resolution of your customers' monitors can affect the readability of your type. For example, most Windows machines are set at 96 dpi, while most Macintosh machines are set at 72 dpi. So, a font set at 72px will be 1 inch (approximately) tall on a Macintosh and three quarters of an inch tall on a Windows machine. Also, some OS's (most often Linux and Unix) can make fonts extremely jagged and hard to read if they try to scale the font sizes from the pixel sizes embedded on the OS. …

—Jennifer Kyrnin

If we pick which rule of thumb applies in creating EPUB files, “accessibility” is the answer. Accessibility is the reason ereaders have font size controls and also the reason why EPUBs are mostly reflowable.

Ereader manufacturers have also provided font guidelines for EPUB developers.

Amazon, Apple, and Barnes & Nobles (B&N) Font Guidelines

Amazon Font Guideline

The Amazon Kindle Publishing Guidelines prohibits developers in setting font size for Amazon format ebooks. Though the Kindle ereaders don’t fully support EPUB, the rules in the guideline aids in EPUB to Kindle format file conversion.


Apple/iBookstore Font Guideline

The iBookstore Asset Guide (downloadable if you sign up for an iTunes Connect account) instructs developers to use em or px for font sizes but also imposes that body fonts or main text should be left alone or should be set to 1em (which also means set to 100%).


B&N PubIt! Font Guideline

It’s unclear why B&N did not include font size specification in there EPUB Format Guide. Subliminally, they must have meant that EPUB developers should not set any font sizes.


Obviously, these three guidelines fairly instruct EPUB developers not to set font sizes, implying that the device should be the one to set the font size. This would seem practical but is somehow limiting for EPUB developers.

Export to EPUB Features of DTP Applications

Well-known desktop publishing applications such as InDesign, QuarkXPress, and MS Word have export to EPUB features and most of them set the font sizes to em units. Printed books that were exported from these applications have helped in spreading of EPUBs that used em for font sizes.


A CSS generated by InDesign CS5

What About Percent?

The third unit, the percentage, though rarely mentioned plays a big part in web design when it comes to CSS reset. CSS reset can also be applied in EPUB development. The HTML5 Doctor CSS Reset is good for EPUB since it hasn’t stripped out the font-style and font-weight values of the <i> and <b> HTML tags. If you want to dive into knowing what CSS reset is, visit the article What Is A CSS Reset.

Percent is also used on drop caps and certain margins in EPUB. The best practice I can think of in using percentage is to first set all HTML tags to a font size of 100%. This will override the browser’s or ereader’s default font size for all tags (this is how the CSS reset works). Then use em units to set the font size for each HTML tag that you’ll use in the EPUB.

So why not use percentage for font sizes all the way? For one reason, we haven’t seen much EPUB files that used percentage to set the font sizes. Second reason, the em unit is used by desktop publishing applications as the unit of measure for font size. We might as well tag along in the use of em rather than use percent and wonder if we did the right thing.


To sum up, it seems that manufacturers don’t want EPUB developers to mess with font size in EPUB. But if we ever do need to set font sizes, let’s take note of WHY we should use a certain unit of measure.


  • Used for accessibility (in web design)
  • Used mostly by desktop publishing applications in export to EPUB feature


  • Used for control (in web design)


  • Least used in EPUB font size

The em unit had the greatest fanbase for font size in EPUB. Perhaps sooner or later, this will be the standard in EPUB development.

The story doesn’t end here though. Not all devices are friendly in the use of em. I believe the e-ink Kindles are somewhat not fond of em units for font size and prefer pixels.

With all these observations, I therefore conclude that we should use em as unit of measure for font-size in EPUB development. If you have any other ideas as to what unit to use, please do share. Your ideas will be greatly appreciated.


After checking how some mainstream ereaders support font units for screen, I've come up with the following output.


The Nook Color and Nook HD uses Adobe RMSDK (Reader Mobile Software Development Kit) which explains why they had the same behavior as Adobe Digital Editions (please excuse the misspell on Adobe Digital Editions in the table).

Monday, May 13, 2013

What’s New in EPUB 3 – Part 2


This is one of the biggest changes in EPUB 3. What used to be a .ncx file in EPUB 2 is now gone and was replaced by an XHTML document that uses the nav element. The XHTML document also has restrictions in the use of certain HTML tags and uses mostly the ol and li tags. This new feature will require a fallback in case an ereader doesn’t support the new navigation system.


Basically, linking is as simple as using an a tag in EPUB 2 and this can still be used in EPUB 3. But the IDPF has established a new registry of linking schemes and one in particular (and the only available as of this writing) seems to be complex to implement. They call it, EPUBCFI or the EPUB Canonical Fragment Identifier. The EPUBCFI closely resembles a Regular Expression pattern.

Scripting and Interactivity

Another interesting, albeit optional, development in EPUB 3 is scripting. In EPUB 2 scripting wasn't allowed. JavaScript is the choice for EPUB 3 and EPUB 3 files will need a query method using epubReadingSystem JavaScript object to determine if an ereading device supports scripting.

Styling and Layout

EPUB 3 uses CSS2.1 with added CSS3 features. EPUB 2 used CSS2. The major change is the required embedding of fonts which uses either an OpenType font or a WOFF (Web Open Font Format). The @font-face is used in the CSS for embedding fonts in EPUB. Font-embed also needs a fallback font in case the ereader doesn’t support font-embedding.

Rich Media

EPUB 3 now boasts audio and video. But wait, weren't we able to play audio and video in EPUB 2? Well, actually that depended on the ereader and Apple was ahead of the game by supporting the audio and video tags which are HTML5 tags. The others, like Barnes and Nobles's Nook, only recently implemented them.

The EPUB 3 Specification on audio and video requires devices to support MP3 and MP4 format audio. Codecs H.264 and VP8 are required for video. Rich media needs a fallback mechanism.


According to the EPUB 2 Specification, the required metadata for an EPUB file are dc:title, dc:identifier, and dc:language. The rests are optional. EPUB 3 metadata specification is much the same, with an added meta property dcterms:modified which defines when the EPUB file was changed.


The Text-to-Speech feature was not in EPUB 2, though iBooks seem to have supported it using VoiceOver. With EPUB 3 there is now Pronunciation Lexicons, SSML, and CSS3 Speech Module.

Manifest Fallbacks

When an ereader can't support HTML5 tags such as audio, video, object, and canvass, an EPUB 3 file will need a fallback mechanism to help the reader identify what a certain misrepresented eBook element is all about. Though setting up a fallback mechanism seem tedious, it is required, especially since EPUB 3 is still a young technology and not all ereaders will be able to support most of the features yet.


There's an issue here as to what the IDPF meant when they said, “There are new restrictions on references to remote resources”. I'll see if I can dig something out of it. The visible change in this part is the extended list of disallowed characters in the OCF file name.

XML and Unicode

IDPF said in EPUB 3, all XML documents must be conformant to XML 1.0. EPUB 2, with the XML declaration <?xml version="1.0" encoding="UTF-8"?">, is XML 1.0 as far as I know. But the <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" ""> declaration is now replaced by <!DOCTYPE html>. I'll also dig into that a little sooner.

These are all the new and changed functionalities in EPUB 3. I'll tackle them in depth in more coming posts and perhaps make a table form.

Saturday, May 11, 2013

What’s New in EPUB 3 – Part 1

O’Reilly has started to make their eBooks EPUB 3 compliant. With this move, they are pushing the ereader development community to do the same, and if is heading for this direction, we might as well follow suit because eventually, that’s where we’re all heading.

After reading the EPUB 3 Specifications in the IDPF website, I tried to condense most of what I know about EPUB 2, compared them with EPUB 3, and chronicled them in this blog.

The following sections are only summaries of what’s new in EPUB 3. I will go into full detail soon after these summaries.

The Content Documents


According to the EPUB 3 Specification, EPUB 3 is XHTML5 which is a serialization of XML and HTML5. But I don’t know if XML will stay. Rumors are spreading that HTML5 will replace XML (i.e., XHTML1.0, 1.1 and XHTML5) altogether. That always happens when a shiny new toy arrives.

EPUB 3 Supports SVG

The Scalable Vector Graphics has, under its hood, XML codes that describe how the graphics will be displayed, thus SVG is actually a vector graphics. So, referring to what I said earlier, if EPUB 3 will support SVG, how will XML die if SVG itself is XML? Maybe the death of XML was really just a rumor.

EPUB 3 Supports MathML

The EPUB 2 format was more of a novel author’s paradise rather than a technical writer’s. This is mainly due to EPUB 2 not supporting display of equations. To display equations in EPUB 2, developers would just use an image for an equation which is outrageously awful. Also, an equation in image format is not accessible and is unusable for the disabled. MathML, an application for XML, tries to solve this problem. If MathML pushes through for all ereaders, then EPUB 3 will be a great haven for technical eBooks.

The Semantic Inflection

If we want to get into further detail about semantics, which we should do because it is required in EPUB 3, I suggest we read Accessible EPUB 3 by Matt Garrish. It’s free for download in For a start, semantic inflection is an addition of an epub tag, say epub:type, which will define an HTML tag. So to add definition to a <body> tag, we would write <body epub:type=”backmatter”>. We can read more information about this here.

Content Switching

Honestly, I don’t have much of an idea about content switching. Some examples of this were the switch and case tags in EPUB 2, but I was never able to use them. EPUB 2, from some of the examples in the IDPF website, used them for MathML. But MathML was not fully supported in EPUB 2. Anyway, now that EPUB 3 supports MathML, these elements have made their comeback as epub:switch and epub:case.

I have covered only a tip of a glacier here which is EPUB 3. I will be posting more and will cover in greater detail each and every aspect of this new eBook format.

Thursday, May 9, 2013

How to Add an Affiliate Banner in Blogger

After rummaging the internet again for such a question I could not easily answer myself, I was able to get hold of some good answers from Peter McCartney and he also mentioned a support site from Google.

It took me a great deal of time searching for an answer so to try and help others out, I’m going to enumerate my procedure on how I managed to add an affiliate banner to this blog.

First off, find the “Layout” button link on your Blogger Administrator Panel. I would assume that you already know what I meant with Blogger Administrator Panel.

You will then see the overall layout of your Blogger Template and will notice that you can add gadgets to certain areas. Proceed by clicking “Add a Gadget” on an area where you wish your Affiliate banner to appear.

The pop-up window “Add a Gadget” will then appear.

Scroll down and look for the “HTML/JavaScript” gadget, then press the plus button.

This will take you to a configuration pop-up window. You can choose not to add a title, for me it looks better that way. In the content box, add the HTML tag for the banner that your Affiliate provided.

Now view your blog. If the Affiliate banner doesn’t appear, try placing it in a different area, or you might try changing your template. Some of the free templates don’t seem to display the added gadgets well.

Wednesday, May 8, 2013

Adobe’s Game – Is It a Win-Win Situation?

A recent news in The Telegraph says that Adobe, Inc. is starting to build its environment in the Cloud. Meaning all Adobe Creative Suite applications will be available only in the Cloud. There last version without the CC will be Adobe CS6.

Indeed this is a bold move for Adobe. The most I could imagine is that, they will have monthly paid subscriptions in the Cloud. Now imagine the number of users that will pay monthly just to float in that Cloud. That’s a lot of money. Can Adobe handle a great load of users when this system is in place? Can they provide security to any copyrighted material? It’s like they’re trying to take control of the whole publishing system.

On the bright side, many companies won’t need to buy new software that only had added features. That’s the way Adobe products seem to be. A new version arrives, with new features and new tools, but the environment is basically the same.

Or so I think it’s a bright side. Thinking again, this is only good for large companies that can afford the Cloud. Small companies that still use, say, Adobe CS3 products, because they can’t afford the price for new Adobe software, are already left behind. And with this system in place, how can they compete in the Cloud? The best they can do is to buy the last version without the Cloud which is CS6 and stick with it forever.

In my holistic opinion, this is a win-win situation for Adobe and large publishing companies. Small publishing businesses will have a hard time running in this race. And when these small publishers go bankrupt, the competition will get narrower, and the prices of printed, or multi, media will skyrocket bringing the larger companies to cloud 9.

What’s your opinion?