Is there any way you can remove me from that service? Appreciate it!

http://flexpaper.devaldi.com

Apple introduced an integrated graphics library and document model in 1994. Thus the graphics primitives and commands to manipulate the graphics primiitives in the systen level libary were a superset of what was used in the document model. This way the problem that Apple QuickDraw and Adobe PostScript were graphics models with different graphics constructs was solved. Apple also introduced TrueType 2 and ColorSync 2 in 1994 as advanced table-based appearance transforms so that in drawing on digital graphic devices it is possible to specify characters and colours at the level of information processing, and apply user-selectable appearances at the level of image presentation. In the presentation image for ‘Adobe Oces’ where is a ligature, Adobe’s approach was to substitute character codes for other character codes (Adobe OYces) whereas Apple’s was to substitute glyph codes for other glyph codes which protected the level of information processing.

So why did the Apple Portable Digital Document model not become an overnight success in the Macintosh customer market when it was introduced in September 1994, at the same time as Adobe Acrobat 2.0. Apple PDD did not support search a. because the input of character information could be in several character sets at the same time with no assurancet of mapping to ISO10646/Unicode, and b. because glyph codes were considered private and font-dependent so that the glyph codes were not a fallback with which to infer ISO10646/Unicode character codes. Adobe PDF allowed that Adobe on the one hand sold type software that changed the customer’s input of character information and on the other hand could recover the character information from font-independent glyph identifiers.

Unfortunately, when Adobe began to sell type software in the intellligent font model of the Unicode Consortium that is supposed to draw glyph alternates, not by substituting character codes but by substituting glyph codes, Adobe chose to sell type software where glyph alternates are mapping to code points in the Private Use Area of ISO10646/Unicode – without product declaration that warns the customer. Again this allows Adobe to claim that PDF supports search, and indeed Adobe does have support for search when overwriting the international standard character set, but the issue is how to get the ISO10646/Unicode character string and the glyph runs that maps from the character infortion through the table-based appearance transforms of the intelligent font model, and the intelligent font model itself into the document model. Which is the core of the current commercial conflict between Microsoft XPS (that does have this ability) and Adobe PDF (that does not).

What the New York Times in 1989 dubbed the Font War was not a war about spline programming languages (Type 1 versus TrueType), but a war about the character model, the font model, and the document model for the change from Print, then Distribute to Distribute, then Print. The war has had cold periods and hot periods, but it has never come to a close.

/hh

When needed (ie, most of the time), the PDF presents the document precisely as its creator intended. Flip a switch, and the text adapts itself to the device’s screen.

To me, this sounds like a solution, not a problem.But there is always going to be an Eeyore in every crowd.

CSS was NOT designed as layout language, it’s simple styling language – the visual experience is poor, it doesn’t support even basics as columns, ascending selectors, scopes for positions or expressions, the fluid model is pain – nearly everything must be manually coded, so it costs hours to look as least ok in major browsers. Instead you can make perfectly nice layout in few seconds/minutes in professional layout environment. I can’t imagine someone to typeset hundreds of pages in html..

There is no good layout language for HTML or XML, and that’s part of problem why monetizing is so hard – web things look visually inferior to pdf, there’s no way to “make” them look better, I have tablet PC and reading pdf is SUPERIOR in every single way to reading webpage – I can even make comments in pdf with stylus and send it with comments to anyone else..

There’s no way any publisher will use HTML and there’s just one right direction – to invent some new content/styling/layout language, which addresses our current needs…

I was one of them to predict and expect a lot from the “papersize PDF to devices” conversion during the iPhone/iPad and tablets launches. but we we look back of the reason they did it, the first reason which cross my mind is that they were lacking time to develop another way.

Many publishers were just too worried to launch their “online presence” on time of the device release, or before their competitor. It’s again, I’m afraid, a matter of conflict between the short term vision to the long term one. I hope they were not just lazy.

I am the one who believes that web standards should prevail, since they offer great flexibility on screen devices.

Very long, but it sounds like you’re saying “the format is wrong” because some uses of that format are not yet the best they can be.

If so, then couldn’t the same could be said of text in weblogs…?

jd/adobe

PDF is the only format that “reflects the typeset page”.

Android has a reader which will “reflow” that page – that is, relaying out the page.

Which is it?

The real problem with PDF, from many consumer users perspective, is that it has chosen the former over the latter. Reflowable PDF files are really an admission that the document should have been in HTML instead where the author does *not* solely mandate the layout.

… But I wonder how much the mobile application store trend, with dedicated news apps and APIs not based on Web standards, undermines not only mobile CSS called from HTML4/XHTML but also HTML5.

Maybe nothing is meeting your criteria, but a general, fuzzy understanding that good design fosters trust and improves readability is being expanded and clarified with serious research. Here’s just one, but it’s among the most cited, so is a good start:
http://portal.acm.org/citation.cfm?id=998272

You might well say that good design can be achieved by any good reader and everyone sticking to standards. But I presume that publishers educated enough to understand this will see no reason it would be better than web browsers. And their content routinely looks awful on one browser or another.

I also would object to your insistence that PDF works too hard because you can zoom so far and get sharp type. All smartphones (AFAIK) use glyphs, not bitmapped fonts, and can do this with ANY application that allows that much zooming. So can any desktop app. It’s inherent in the OS, regardless of sending the type descriptions over which PDF does.

We’re also starting to get printing from handsets, display on larger devices (and I mean TV sized, not just tablets). It better be able to support that as well.

Perhaps the solution is as you describe above, overflow a column for sliding, and both presentation and user needs fit the device appropriately for 4″, 7″ and 10″ and even GoogleTV readable user experiences.

We as content creators need the Framework designers out there to act upon what you have crafted here, and do what needs to happen.

As for publishers taking to PDF (and I am a technical publisher), it is really the only format that accurately reflects the typeset page. WYSIWYG.

My one frustration with PDF is its inability to limit copying and printing of individual .pdf files. I’ve spoken with Adobe twice on this matter, and they have been unable to come up with an internal locking mechanism.

Thus, for publishers for myself, the greatest failing of PDF is that enables piracy of our technical documents.