Covers: Will Rendered Text Cause Rejection?

Just wondering if you create a cover that is 100% rendered image (no text overlayed, etc), will Apple reject the book? Do we have to make covers where the graphical elements are background for the text?

I just tested this, because I didn't know the answer. Words in text blocks placed on the cover are NOT found when the reader performs a search.
Nor are they used by Apple as searchable metadata.
Charle Stack
Author
iBooks Author Guide

Similar Messages

Trying to OCR pdf, pdf says it can't perform bc it already contains renderable text-but does not.

I work for a large agency, and we receive PDF's all the time. 98% of the time I am able to OCR a document with no issues. Just recently I have come across this issue several times, and was wondering if anyone can solve this irritating problem!
*Acrobat 8.1 - When going to OCR the document, I receive the following message " Acrobat could not perform recognition (OCR) on this page because this page already contains renderable text. However, it does not. When you go to select text or search for anything the whole page is selected (like it's still in a "picture" format, not a document format that you can search, ect.)
I am not sure if it is how the document is uploaded originally by the other party that causes this, but the only thing I can do as a work-around - is to print out the entire document, scan and then I can OCR the document just fine! The problem is, if the document is 400 pages or so, this can be a huge waste of time, and money just to be able to search the PDF.
*I have also checked the pdf properties to see if this is some sort of permissions issue, and there are not permissions/security settings in place.*
PLEASE HELP! Any assistance in this matter would save me a lot of time, and of course (my sanity!).
Thank you in advance!

While the alert speaks to "renderable text" that is a simplification. The issue is that you've PDF page content consisting of at least one renderable "character".
Look at font families - you will observe that there are many characters that are not "text" characters (i.e., linguistic characters).
So, there's a "renderable character" present. It may be an alpha numeric that has a font color the same as the page background. It may be under the image and thus not visible to the eye.
You might be able to determine just what is present.
You could export the page of interest to a text file then view that file.
You could deplay the page of interest in Acrobat Pro then select the "Content panel" to view the content tree.
Locate and click on the page number for the page of interest.
From the Content panel's Options menu select "Highlight Content".
Walk down the tree. Select the content containers in turn and observe what is highlighted on the PDF page.
Where might the renderable character come from ? Typically that'd be associated with something in the work flow.
Not always easy to find so don't take anything in the work flow for granted.
Be well...

How to recognize text in XI Pro when files returns "renderable text" error.

This same file will recognize text & provide searchable document in Adobe 9.
I saw workaround to convert each page to TIFF, do OCR on each page, convert each back to pdf & combine. That is ridiculous. Will there be a new version of XI Pro that will work correctly for OCR?

Varinder.Saini wrote:
David,
That is how it is. If you run Searchable Image or Searchable Image (Exact), Acrobat will throw error only for pages that contains renderable text. It also gives an option to ignore these error for any further pages containing renderable text.
If you check this option it will run OCR for rest of the pages and won't show the error again for that PDF.
This option is not available when OCR'ing using Adobe ClearScan -- ClearScan being the ONLY reason anyway why I own Acrobat Pro AT ALL -- for it's otherwise ridiculous slowness compared to its competitors. Sorry having to tell you that, from the point of view of having worked in a paperless law office for 15 years, therein 4-9 hrs a day with PDF documents usually in the 600 to 1.800 page range.
CtDave wrote:
Precluding the entry of anything 'renderable' assures OCR will be accomplished for each page.
David Peters wrote:
Just stop bullshitting users about "you better follow well defined protocols" niminy-piminy-finicky.
There is zillions of cases where one does not have ANY control neither access to the (external) creation of one's PDF files, even if people like you seem to be unable to imagine, and therefore repeat the same pointless sermon over and over that does not add ANYTHING to the case.
The solution to this problem by the way is not a question of more (lost) decades of rocket science Adobe bloatware engineering, but simply:
If there is "Renderable Text" somewhere on some fuⅽʞing page:
then just SKIP IT and continue OCR with the next fuⅽʞing bitmap
gosh darn it.
Not that I would hope that any of this would change anything with the course of the megaton tanker Adobe which I usually avoid like the plague -- with the only two exceptions of ClearScan and of course, Acrobat 7 Pro, the last Acrobat version that was not only fairly usable but actually is a pretty amazing piece of software.

Keep getting "renderable text" error when I need to OCR PDF's from FrameMaker.

My solution has been to individually extract all those pages, then open them up in Photoshop, flatten them and
widen the canvas size to standard 8.5 x 11.
But that's a little tedious and time-consuming and you have to delete the original page from your document, after
importing the OCR-friendly page.
Is there a printer definition, or something you can set up when you're generating your PDF's in the first place,
that will get rid of that annoying "renderable text" error?

Ok...
I don’t know how it happens but after I save my work in FrameMaker or MS Word, and print
to PDF for the final output, there are often pages with text in them that isn’t recognizable,
or that can’t be found with a CTRL+F search.
That is a serious issue, and one we might be able to help you with, but really, quite separate from the issue here. It's too late to try and fix this once it is a PDF.
What is it that’s lost when OCR is run?
Quality. Small file size. Tags (which might be required legally). Almost everything except the basic text, and that might also be lost given that OCR is not guaranteed to work. This is NOT the right way to solve your problem.
The translator doesn’t have any Adobe products except Reader, so I’m limited to Acrobat
to show her how the words and pictures are laid out on a page.
In order for her to copy and paste that text – or search it, to find all of the places where the
same word might be used – I need to make sure every word is there for her to grab.
I have heard of translators trying to work with PDFs, and few that succeed. You can reasonably expect a transation service to support FrameMaker. But if they don't I recommend you extract the text from FrameMaker to a simple Word or text file. They should be fine using the PDF as a visual reference, and having the text to translate, and for you to flow back into the original layout. (Again, something I'd expect a full service translation to do themselves, but there are advantages to keeping control too).
Those were the 2 pages that gave the ‘renderable text’ error. Don’t ask me why or how, they
look like all the other pages in that document. Except Acrobat thinks they’re scanned graphics,
that’s how they present when you wave the cursor around in them, hunting for text.
Renderable text is just text. It means that somewhere on that page there is text. Surely there is layout, page numbers, whatever from FrameMaker on the pages. If not, we really need to look at your production methods - back to the first point.

BUG - in flash pro CC, 'bold' and 'italic' properties of TextFormat have no effect on rendered text

Concise problem statement:
If you compile with flash pro CC, and use the 'setTextFormat' method of a TextField, the 'bold' and 'italic' properties of the TextFormat argument have no effect on the rendered text. If you compile with flash pro CS6, the 'bold' and 'italic' properties work as expected.
Apparently, with flash pro CC, the only way to make the text render correctly is to change the font name (add the suffix ' Bold', ' Italic', or ' Bold Italic'.) This means code which dynamically changes font styles only works in CS6 or CC, but not both. For example, if you use the 'bold' property the text renders bold in CS6 and regular in CC, whereas if you change the font name to add the suffix ' Bold', the text renders bold in CC and DOES NOT RENDER at all in CS6. This makes it difficult to transition a team from CS6 to CC.
Steps to reproduce bug:
1. Create an xfl with 2 TextFields on the stage, both with font "Trebuchet MS" and style "regular", one named boldTrueText containing the String "bold = true", one named fontNameText containing the String "fontName = Trebuchet MS Bold". Create 2 more TextFields on the stage for visual reference, both with font "Trebuchet MS", one with style "regular", one with style "bold".
2. Add the following code to the Actions panel on frame 1:
import flash.text.TextFormat;
import flash.text.Font;
var format:TextFormat = boldTrueText.getTextFormat();
format.bold = true;
boldTrueText.setTextFormat(format);
format = fontNameText.getTextFormat();
format.font = "Trebuchet MS Bold";
fontNameText.setTextFormat(format);
var fonts:Array = Font.enumerateFonts(), count:int = fonts.length;
for (var i:int = 0; i < count; i++) {
var font:Font = fonts[i];
trace("fontName: " + font.fontName + ", fontStyle: " + font.fontStyle);
3. Save, and compile with flash pro CS6 and flash pro CC.
Results:
With flash pro CS6, "bold = true" renders bold, and "fontName = Trebuchet MS Bold" DOES NOT RENDER.
With flash pro CS6, the following is traced:
fontName: Trebuchet MS, fontStyle: bold
fontName: Trebuchet MS, fontStyle: regular
With flash pro CC, "bold = true" renders regular, and "fontName = Trebuchet MS Bold" renders bold.
With flash pro CC, the following is traced:
fontName: Trebuchet MS, fontStyle: regular
fontName: Trebuchet MS Bold, fontStyle: bold
Expected results:
The same text is rendered in both flash pro CS6 and CC. I don't know why this behavior was changed in flash pro CC - it causes silent failures in code which dynamically changes font styles. I expected the flash pro CS6 behavior to remain the same in CC, like so:
With flash pro CC, "bold = true" renders bold, and "fontName = Trebuchet MS Bold" DOES NOT RENDER.
With flash pro CC, the following is traced:
fontName: Trebuchet MS, fontStyle: bold
fontName: Trebuchet MS, fontStyle: regular
If you don't want to break backward compatibility (any further), you could make both the behaviors work in flash pro CC, like so:
With flash pro CC, "bold = true" renders bold (font is still "Trebuchet MS"), and "fontName = Trebuchet MS Bold" renders bold also.
With flash pro CC, the following is traced:
fontName: Trebuchet MS, fontStyle: bold
fontName: Trebuchet MS, fontStyle: regular
fontName: Trebuchet MS Bold, fontStyle: bold
I submitted this bug with the bug form, and also with adobe bugbase (in case it isn't obsolete) - I'm just trying to maximize my chances of getting a fix. Has anyone else encountered this bug?

I just can't believe how there is ZERO documenation for any of this. Flash's stylesheets have fontStyle and fontWeight properties, but they only recognize regular/italic and regular/bold respectively.
This change in Flash CC completely breaks systems built in Flash CS6, and the font naming is actually arbitrary and is not a consistant combination of font name and style (e.g. "Eras ITC" family's bold font name is "Eras Bold ITC", but the bold version of Times New Roman is "Times New Roman Bold" (with Bold at the end, rather than the middle), and what's absolutely appaling is that the font name used at runtime is not exposed anywhere in the Flash IDE!!! In the IDE you select a font family and font style independently, which is absolutely not what's used at runtime, because it actually uses a separate, arbitrarily named field in the font file for the font name. So we can't even know from within Flash what the proper runtime name is, unless we trace it out or open the font properties details tab in Windows explorer.
It seems that Flash CC is always using the font "Title" that can be found in the properties of the font, NOT the font name displayed in Windows Font Preview or in Flash CC. For example, the font name for Times New Roman Bold in Windows Font Preview is just "Times New Roman", but the font title in the properties/details tab is "Times New Roman Bold". If they made the change to allow for specific fonts to be selected, that's fine, but it completely breaks HTML support in TextFields if it's not respecting bold and italic tags.
This may actually be a trend on the web now, if you read this: http://www.smashingmagazine.com/2013/02/14/setting-weights-and-styles-at-font-face-declara tion/ , it says: "If you’ve used one of FontSquirrel’s amazing @font-face kits, then you’re familiar with this approach to setting weights and styles. The CSS provided in every kit uses a unique font-family name for each weight and style, and sets the weight and style in the @font-face declaration to normal. [...] Notice that the font-family names are unique, with each font-family name accessing the appropriate Web font files."
But there's just no mention of this in any documentation I can find. What the hell.
It's also helpful to realize that font and u tags have been deprecated in HTML5, while b and i tags have been repurposed since they still retain semantic meaning apart from style: https://www.w3.org/International/questions/qa-b-and-i-tags

Renderable text and indexing

My ultimate goal is to have as complete a “Full Text Index” as possible. To that end, I have a couple of questions. I have both scanned pdfs and pdfs that have been created from word or powerpoint and have renderable text.
for those files with renderable text
If a page has renderable text, is all of the text included when the “Full Text Index” is built?
If a page has renderable text and an image, is the text within the image ignored when the “Full Text Index” is built?
If I OCR the document, if a page has renderable text and an image, is the image ignored during the OCR process?
If I OCR the document, if a page has an image and no renderable text, is the text within the image recognized during the OCR process?
Thanks.

1. If a page has renderable text, is all of the text included when the “Full Text Index” is built?
The key question is "Do the renderable texts' fonts map to Unicode?" Fonts that map to Unicode are searchable.
Such will be harvested by the Catalog index.
Using Acrobat Pro you can create a preflight to check for this.
2. If a page has renderable text and an image, is the text within the image ignored when the “Full Text Index” is built?
Ok, a scanned image of text has no "text" just pixels that look like text - it is all just an image.
So, nothing to be harvested by the Catalog index. The page's renderable text will be harvested by the Catalog index.
3. If I OCR the document, if a page has renderable text and an image, is the image ignored during the OCR process?
A page of a PDF that has renderable text cannot be OCR'd.
Provided the page's content is an image containing pixels representing characters OCR will attempt to recognize these and provide an output.
If Searchable Image or Searchable Image (Exact) is used the "recognized" output is a hidden/invisible layer (text rendering mode 3 - no stroke, no fill).
The scanned image remains on the page. Searchable Image 'tweaks' the image. Searchable Image (Exact) does not.
So, for both you have the scanned image and the hidden layer of OCR output.
Alternatively, if you use ClearScan recognized characters (in the image) are replaced with an Acrobat generated font.
Anything not recognized is left as a bitmap of the 'character'.
So, the image is not ignored by OCR as it is what OCR analyses to recognize characters for providing an output.
A Catalog index will harvest the OCR output of any of the three OCR modes.
4. If I OCR the document, if a page has an image and no renderable text, is the text within the image recognized during the OCR process?
OCR will attempt to recognize the pixels that represent characters and when recognized provide an output.
A Catalog index will harvest the OCR output.
Be well...

OCR renderable text error

someone was having the problem below with an older version of acrobat.
is there now a solution in acrobat mac x?
i note that exporting to image file loses quality and increases file size
thanks
Well, since this is the digital age, it makes sense that I ought to read the PDFs in digital form (this is a stretch for me, I really like paper), which is facilitated by a tablet since I can actually see the page when it’s in the portrait configuration. It also makes sense that I ought to mark up the file in Acrobat, using the native highlighting and searching tools, which is also facilitated by the tablet for obvious reasons.
Here’s the problem. Apparently *every* PDF file, in every digital library, is tagged with headers, or footers, or bates numbers, or some other tag that halts the OCR recognition of the PDF file. If you google “This page contains renderable text”, you’ll see that this has been a complaint since Acrobat 6 at least. So you can’t just OCR the document and get a nice, mark-up-able document.
Now, I know what you’re thinking. There has to be a workaround, right? Of course, there is. You can manually remove the headers and try again. Oh, now there’s a footer; you can take that out too (manually) and try again. Oh, now there’s a bates number, okay, take that out too. There’s STILL some renderable text in there somewhere, well, now you can either try and edit out the blocks of renderable text (again, manually, made more entertaining by the fact that you can’t just right click on the page and say “remove renderable text”), or you can export the entire document to a graphics file (say, a TIFF), re-convert it to a PDF file (which turns the entire document into a rasterized image), and THEN run the OCR tool to get an actual mark-up-able document. This process is made more enjoyable by the fact that Acrobat will turn that 300 page dissertation you’re reading as part of your research into 300 distinct TIFF files, which you then need to recombine into a PDF file. Multiply this by 100, and you’ll see what sort of a barrier to productivity this is for me to get started organizing my existing document collection.
This is CLOSE TO THE DUMBEST THING I HAVE EVER SEEN. And I’ve seen a LOT of bad design. Rather than prompting me “This document has renderable text” and giving me “Cancel” as the only option, any feature-driven developer would say, “Gosh, people get really frustrated by this. I know, because I can read the results of a simple google search. We need to change this right away! Here, I’ll make it so that you can just click ‘Treat existing renderable text as white space’ or even prompt the user to rasterize the renderable text and embed it in the document, then OCR the resulting file!”
The only conceivable reason I can imagine that this hasn’t taken place is because your lovable electronic document vendor wants to make it a colossally, enormously painful process for someone to actually do anything to the document they’re providing you to use. Thank you, electronic document vendor. You’re going to be wasting about 20% of the time that you’re saving me by giving me electronic access to this document in the first place.
Progress is grand. Collide it with self-interest, progress seems to lose out more often than not.
Now, if you’ll pardon me, I’m going to go get some sleep. Then I’m going to get up in the morning and go to work. Then I’m going to come home, and instead of enjoying some family time with my kids, I’m going to fart around with manual document conversion.

Elias,
I completely agree with your anger. I ran into the same problem and I think I have figured out a workaround. I wrote up a blog post about it.
http://www.ideationizing.com/2011/03/ocr-acrobat-pdf-with-renderable-text.html
I hope this works for you.

Audio renders are causing general errors

It seems when I use an audio effect and render I sometimes get general errors. I t is usually when there are a few tracks of audio. If I take the edits and put it in a new sequence sometimes it works other times I just get a general error. It is very frustrating cause what I have to do is add each layer on to a new sequence to see which of the renders are causing this problem.
help?

"filers?"
No additional plug ins, just the apple ones. maybe a
reverb or a slow down.
will try repairing disk permissions and yes formatted
mac extended and lots of space on a Terrablock
system. Fiber channel drive system. Not happening
in anywhere else except when filers are used for
audio.
thanks

Invoke-WebRequest - Unable to get rendered text

Hi
This issue exists in powershell but I suspect this issue will exist no matter what language is used.
The problem is the rendered web page has chat text.
However no matter what I do in powershell I can't get to this text.
If I do a "view source" in IE or Chrome the text is missing, if I pipe the parsedhtml to a file, it is missing,
So below you can see the original screen and F12 debug says the text lives inside "rooms-view-right-pane"
Visibly you can see it, programmatically you cant see it
>> So what is the magic that is missing , stopping me from capturing the rendered text ?
Thanks in advance
<div class="rooms-view-right-pane">
</div>
</div>
</div>
</div>
</div>
</div>

Well for what it's worth, you can have what is below. I ain't proud of it - it's pretty dodgy, but in this example it retrieves points for a profile. The number of points does not appear in the source, only in the generated source.
It would be easy to keep it checking the page and comparing the new value for the points with the old...
Like I said, there has to be a better way.
GenSource.hta
<html>
<head>
<title>GenSource HTA</title>
<HTA:APPLICATION ID="oHTA"
APPLICATIONNAME="GeneratedSource"
SHOWINTASKBAR="no"
ICON=""
CONTEXTMENU="no"
SCROLL="no"
SCROLLFLAT="no"
SELECTION="no"
SINGLEINSTANCE="yes"
SYSMENU="no">
<meta http-equiv="x-ua-compatible" content="ie=9">
<style type="text/css">

</style>
<script type="text/jscript">
window.onload=function(){
window.resizeTo(500,350);
window.moveTo ((screen.width/2-204),(screen.height/2-200))
wClose.onclick=function(){close();};
document.all.frame1.src="https://social.msdn.microsoft.com/profile/greg%20b%20roberts/?ws=usercard-mini";
function frameloaded(){
var frameEl=document.frames["frame1"].document.getElementById("points");
if(!frameEl||frameEl.innerHTML=="-"){setTimeout(frameloaded,500);}
else{
el.innerHTML=document.frames["frame1"].document.getElementById("displayName").innerHTML;
el2.innerHTML=frameEl.innerHTML+" points";
</script>
</head>
<body>
<div id="wClose">X</div>
<iframe width="500" height="200" id="frame1" onload="frameloaded();">Test Page</iframe>
<div id="el" style="font-size:20px;color:#fff;width:500px;height:30px;margin-top:20px;"></div>
<div id="el2" style="font-size:20px;color:#fff;width:500px;height:30px;margin-top:20px;">Loading...</div>
</body>
</html>

Rendered text problems in 5.1.2

I am working on a film project that has a lot of subtitles. (The dalies are digitized at HD DVC-Pro 720p) I was editing on a station running Final Cut Pro 5.1.1 (g5) with no real problems. I recently took the project with me on a trip to work on using my macbook pro (intel) running 5.1.2. I have discovered that all of my rendered text in my timelines is now uneditable. I can't move the text, I can't change the text, I can't even delete the text. I also can't change any of the footage running underneath the rendered text. It has become an immutable part of my film. This is obviously a huge problem. Has anyone else run accross this problem? Is it something that Apple is aware of? Any fixes? If not I may have to move to Avid and start all over again.

Not that strange, really. Several different NLEs can sometimes lock onto a render file and not update the output until that render file is deleted.
Rather simple fix, just a little time consuming.
Next time don't be so quick to threaten to jump ship. First problem and you were ready to move to Avid. I've had more problems working on Avids than I have on FCP. MANY more problems. FCP problems are usually due to user error or third party hardware. Avid problems shut you down for a couple weeks while you ship out your hardware.

My itunes will not open cause it says itunes requires quicktime 7.5.5 or later but i have quicktime 7.2

My itunes will not open cause it says itunes requires quicktume 7.5.5 or later but i have quicktime 7.2 installed already on my mac

Hi, try this...
http://www.apple.com/itunes/download/

When I click Buy Book this appears our book appears to have default text that has not been edited. Printed books will not include this text. Do you want to continue? will the text I have sellected still be ok or will the book have missing text help Pleas?

I just spent 3 days creating a book [32 pages], with photos and text but when I click Buy Book In iPhoto this appears>
Our book appears to have default text that has not been edited. Printed books will not include this text. Do you want to continue?
My question is will the text I have sellected to use still be ok, am I safe to continue and buy or will the book have missing text ?
The book is for special birtday in 2 weeks time Please Help.G
<Email Edited by Host>

Yes, you're safe to continue. That means that there are text boxes that you did not put any text into and they contain the holding text which will not be printed. That text is shown in a light grayt and is in Latin. Normally you can just put a space in the text box to replace the holding text so as not to get that warning message.
Before ordering the book proof the book according to this Apple document: iPhoto, Aperture: Previewing an order in iPhoto or Aperture. Check the pdf file for any missing text or photos and any warning indicators in the text boxes indicating that some of the text has exceeded the space allotted in the text box.
Keep the pdf file to compare with the printed copy when you reciive it.
OT

How can I get rid of numbers that are covering my entire desktop, caused by right-clicking "Clean Up Selection" on an icon?

How can I get rid of numbers that are covering my entire desktop, caused by right-clicking "Clean Up Selection" on an icon? The Apple OS X Mavericks blue & green desktop is totally gone. HELP!

Here's a screenshot of my desktop, as of a few minutes ago: http://lewgoodman.com/desktop.tiff

When throwing Warning Message from EOImpl, Text, Cause and Action is coming

Hi,
When I am throwing JBO Exception through EOImpl code, I am getting warning message with Text, Cause and Action, But my aim is to get only Text message.
/* Code used */
JboException e = new ApplcoreException("Message Code");
e.setSeverity(JboWarning.SEVERITY_WARNING);
throw e;
/*end*/
Please suggest some approach.
Thanks
Ankur

Applcore is not availble to the Outside world , so better to post this on the internal ADF Frontend forum.
I suspect there might be another API to do this .

Rendering text

I am rendering a video that contains a substantial amount of text, perhaps accounting for 50% or more of the entire scene content.
It is agonizingly slow, leading me to believe that rendering text is significantly slower than captured material.
Is this correct?
Thank you.

Which text generator(s) did you use?
I haven't found that the text generators require noticeably more rendering time than most other transitions or effects.
You do have +a lot of text+ in your sequence - +" ... 50% or more of the entire scene content ..."+ - that's a lot of material to have to generate & render.

Covers: Will Rendered Text Cause Rejection?

Similar Messages

Maybe you are looking for