Unfortunately, many PDF authors just "point and click" to create their documents. Often, you can dramatically reduce the size of a document (PDF) by careful consideration of its content -- as well as the chosen authoring tool(s)!
I was stunned, one day, to discover a final size of a simple document that was MUCH larger than I would have anticipated! On closer inspection, I discovered that one of the high resolution images that I had imported, panned and scaled (to highlight a particular SMALL PORTION of the image) was actually present IN ITS ENTIRETY in the PDF! Even the parts not intended to be "visible" in the document!
Also, blindly including ENTIRE "fonts" (instead of risking them being absent from the user's system) can add a lot to the file's size (think about those docs that have notices in 5 different languages -- including non-european languages!).
Documents that are intended to be viewed on a screen have different requirements than those intended to be printed. Color images take more space than monochromatic. The more colors, the more space! (do you really want a 24b TIFF embedded in the document? are you expecting the user to zoom to incredible levels and still preserve detail -- sometimes you do!)
Supporting different PDF versions also comes at a cost.
It's entirely likely that their document prep folks just have a canned way of creating ALL pubs. After all, storage and bandwidth are presumed to be FREE! :-/
Did you notice that the Atmel "complete" datasheets contain the complete reference manuals of the particular chips? Just have a look at the page count and the index...
What other makers call "datasheet" is called "summary" at Atmel. These files are significantly smaller.
Compare the size of Atmel's datasheets with those from Microchip which have comparable levels of detail. All the Microchip ones are _much_ smaller just like the Atmel ones used to be in older versions of the Atmel datasheets.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
|Hello Simon Clubley, | |Thank you for contacting Atmel Technical Support. | |We have informed your suggestion to the concern team, hope this will |be resolved soon. | |Thank you for your suggestion.
Who knows, it might prompt someone to check their PDF creation settings. :-)
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Be careful what you ask for, you might just get it. I'd rather have images in a PDF file that were large, but with sufficient detail that I can zoom in and see them clearly than to have a smaller file and not be able to read the fine print. I can't tell you how many times I have not been able to read text contained in a diagram or sometimes even the caption/title of the figure.
The resolution of an image is relatively easily controlled. There's a point at which it doesn't make sense to support "infinite zoom". (e.g., a photo of an author on a dust jacket)
Text, OTOH, if done properly, *can* be zoomed indefinitely -- as it is rendered from a *model* ("font") and not stored as an image.
Of course, this assumes the document preparer knows how to separate text annotations from the "images" to which they apply!
All I can tell you is that new revisions of the same AVR datasheets have been jumping in size over the last few years, but this jump to 35Mbytes is a new low for Atmel.
That's 35Mbytes for 660 pages. I still have a ATMega168 datasheet from
2007 which is 376 pages and that is under 5Mbytes (and all the diagrams are perfectly readable).
Microchip still manage to do what Atmel used to do and represent similar amounts of information in much smaller PDFs. The datasheet for the PIC32MX2xx range is 330 pages and just over 6MBytes in size.
The user manual for the LPC81x range (cute little MCU BTW) is 370 pages and just under 2Mbytes in size (although there appears to not be as many diagrams in that case).
Oh, and Atmel dumping that stupid distracting blue bar at the top of each page of it's current datasheets would be a good thing.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
The diagrams, if done properly, can be zoomed indefinitely just as well. Simply because PDF allows for not only "model-based" fonts, but also rather arbitrary graphics.
To me, the most apparent issue with Atmel PDFs was the design change; FWIW, I can no longer be sure that I get a nice result when printing one on a monochrome laser printer. But I hope to check the sizes shortly, too, -- who knows, the issue may be easy to solve just by "converting" PDF to PDF with suitable GhostScript settings. (Or perhaps I'll try PDF::API2.)
--
FSF associate member #7257 http://boycottsystemd.org/ 3013 B6A0 230E 334A
Yes, but you have to choose how the diagram/image is represented. E.g., a TIFF will, eventually, become pixelated. OTOH, vector art will scale just like a "font" (same approach). E.g., use something like Illustrator to prepare your "figures", not "Paint".
You can use color in documents -- but, you have to consider *which* colors and in which combinations. You need sufficient "value change" to give acceptable contrast. E.g., using yellow callouts on a white field is probably going to disappear when rendered monochromatically.
This shouldn't be rocket science. Prepare document. Print it. See what it looks like. Revise color choices/layout/etc.
Ditto for file size.
Adobe products have lots of redundancy in their file formats. Previews, etc. Make sure the stuff you actually need -- and no more! -- is dragged into the PDF.
Also, think about what is creating the PDF. Sometimes, a "PDF printer driver" produces a smaller PDF!
Actually, it's comparable in so far as it's the same type of text and diagram layouts between the Atmel and Microchip documents.
However, your mention of the PIC32 FRM caused me to take a closer look at it. I have two versions of the FRM to hand: an old monolithic version from 2008 and the PDFs making up the segmented version which I downloaded about 2.5 years ago going by the date stamps.
The old monolithic version is 12484111 bytes and contains 1138 pages.
The combined full size of the PDFs I have to hand from the segmented version is ~20MBytes and contains 1155 pages in total. Here's the breakdown:
However you look at it, the Atmel PDFs are massively oversized (especially since I remember the size they _used_ to be. :-()
BTW, pdfinfo (which I used along with some bash shell scripting to produce the above table) reveals both Atmel and Microchip use FrameMaker and Acrobat Distiller to produce the PDFs.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
As I said previously, they are clearly doing something "wrong" -- or, have an entirely different set of expectations for the document that isn't apparent to the casual user. Pointy-clicky interfaces tend to produce users who think ALL they need to do is "point and click"!
Atmel-8285-8-bit-AVR-Microcontroller-ATmega165A_PA_325A_PA_3250A_PA_645A_P_6450A_P_datasheet.pdf has a downloaded size of 62,477,528 bytes.
I created a version that is 7,102,901 bytes. Had I access to the original "sources" -- and, more motivation (beyond a 90 second investment) -- I am sure *something* smaller than 60MB is easily possible!
If you look at the *content* of the Atmel PDF, you will see that a LOT of it (> 50MB!) is "Document Overhead" -- stuff that isn't pertinent to the actual delivered *content*. I suspect the authoring tools that they used for the illustrations AND text have added "private data" that they did not make an effort to STRIP from the final document. Things like "previews"/thumbnails for the illustrations, etc. I haven't looked in detail at the content to identify the tools that they actually used for these things... ("it's not my job..." :> )
I would guesstimate that the "ideal" delivered size would be in that ~7M ballpark -- perhaps a bit higher for some of the dynamic aspects of the document.
Never. Worst part of my week -- EVERY week! :< Unfortunately, "gotta eat"!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.