Forgot your password?
typodupeerror
Security

PDF Vulnerability Now Exploitable With No Clicking 206

Posted by CmdrTaco
from the don't-not-click dept.
SkiifGeek writes "With Adobe's patch for the current PDF vulnerability still some time away, news has emerged of more techniques that are available to exploit the vulnerability, this time without needing the victim to actually open a malicious file. Instead, the methods make use of a Windows Explorer Shell Extension that is installed alongside Adobe Reader, and which will trigger the exploitable code when the file is interacted with in Windows Explorer. Methods have been demonstrated of successful exploitation with a single click, with thumbnail view, and with merely hovering the mouse cursor over the affected file. There are many ways that exploits targeting the JBIG2 vulnerability could be hidden inside a PDF file, and it seems that the reliability of detection for these varying methods is spotty, at best."
This discussion has been archived. No new comments can be posted.

PDF Vulnerability Now Exploitable With No Clicking

Comments Filter:
  • by forand (530402) on Thursday March 05, 2009 @09:51AM (#27076461) Homepage
    This vulnerability is not inherent to PDF but to Adobe's implementations.
    • by OpenGLFan (56206) on Thursday March 05, 2009 @10:08AM (#27076609) Homepage

      Adobe's particularly horrible implementation.

      Right now, on my laptop, I have two VirtualBox sessions running images pretty close to the servers at work. I'm testing out some simulation. I've got slashdot open in Firefox, and I've got Adobe's PDF reader open to a reference manual.

      The PDF reader is using more memory than the two virtual servers combined. That's a ridiculous amount of bloat, and it doesn't even count the "Adobe Updater" software that runs all the time.

      • Hmph. Doesn't surprise me. The Adobe Acrobat Reader setup pinned my CPU for a solid 5 minutes and consumed more memory than Firefox consumes even at its worst.

    • by gravos (912628) on Thursday March 05, 2009 @10:12AM (#27076651) Homepage
      If you use Windows try this alternative implementation: Sumatra PDF Reader. It's Open Source, less than half the size of Foxit (1/15th the size of Acrobat) and has search, text-read, copy-paste, and plenty of keyboard shortcuts. It's very quick and streamlined and makes Foxit look bloated in comparison. And naturally it's not affected by this vulnerability.
      • by Dwedit (232252)

        Sumatra Reader can't select text.

        • by Your Pal Dave (33229) on Thursday March 05, 2009 @12:36PM (#27078407)

          It's not obvious, but if you hold down the control key while mousing text is selected and automatically copied to the clip board.

          Once you get used to it this is actually quite convenient.

      • by richlv (778496)

        and the yellow page design hurts my eyes.
        i couldn't find a feature list, but i assume that saving filled forms (or form support at all ?) isn't available.
        while it has potential, feature parity and exceeding will be required to gain some serious marketshare.

      • Re: (Score:2, Informative)

        Eh, it's buggy. I just installed it, and after 4 seconds figured out I can't even scroll with PDFs on "Facing" mode (how I primarily use PDFs).

        Also there's no toolbar buttons like in Acrobat for changing the view.
        I think I'll stick with Reader 7.0.x + ARSpeedup for now.

    • by hey! (33014) on Thursday March 05, 2009 @10:28AM (#27076805) Homepage Journal

      It's kind of a flaw that is endemic to the commercial software development model. This is not to say that that model is useless or F/OSS doesn't have its own problems.

      The root of the problem is how we "add value" to a piece of software. Since with F/OSS, software development has a service model, you mainly add value by adding services: documentation, support, consulting. You can't "add value" by adding features to the software, at least if you try to you only get paid once for doing so.

      A proprietary software developer can get paid multiple times for adding a piece of value into the software. For software that is sold, this is driven by market segmentation. The least pernicious form of this is the ubiquitous "bronze/silver/gold" model where they try to maximize their return from cheapskates, pragmatists and spendthrifts respectively. If you are cheapskate who needs a feature in the "gold" edition, you're out of luck. In the worst case, it drives a bewildering proliferation of "products", as vendors try to find the division of features that maximizes their returns (which is an instance of the NP-Complete "integer programming problem", only approximations are practical). From a customers standpoint, it sometimes looks like a whirlwind has picked up all the features and dropped them into random pigeonholes.

      The "value adding" imperative still applies to free as in free beer proprietary software. In such cases, the developer still is looking to get paid, only in different coin, e.g. control of formats and the market power that comes with it. Adobe benefits from PDF being a non-proprietary format because it encourages adoption, but it is risky because they wouldn't benefit if they did not control the dominant implementations of PDF technology. And they try very hard, I think, to have the best implementations, which leads to the old problem of adding value by adding features. The hope is that by adding features nobody has asked for, when those features are missing from a different implementation, that implementation will be seen as less complete and polished. I think this often works, but it leads to this kind of blowback siutation: security flaws introduced to users systems along with features the user never asked for.

      • as vendors try to find the division of features that maximizes their returns (which is an instance of the NP-Complete "integer programming problem", only approximations are practical)

        Deciding four-colorability of planar graphs is O(1)---that's the famous Four Color Theorem---so it's in P so it's in NP so it reduces to SAT, integer linear programming and god knows what else.

        Does that mean that only approximations to "bool fourcolorable(graph_t *G) { return true; }" are practical? Return true some of the time? I think it looks perfectly practical. In fact, it scales perfectly to any number of graphs ;-)

        If you're claiming that integer linear programming reduces to "Vista Segmentation" a

      • by nurb432 (527695)

        It's kind of a flaw that is endemic to the commercial software development model.

        Yup, the true price of bloat.

    • by ladybugfi (110420)
      You are mistaken! Open source implementations also got it wrong, it isn't just Adobe. See for example problems in poppler here [vupen.com]. Since there are apparently different problems in several independent JBIG2 format implementations, maybe the format specification isn't as clear as it should be?
  • Since PDF is Portable, does it affect other platforms as well. Or is it Windows specific? Does it affect other libraries than the Adobe ones? And why the fsck does a freakin' DOCUMENT have scripting in it? I can understand form elements but not something akin to shell scripting.

    • Re: (Score:3, Informative)

      by Camann (1486759)

      does it affect other platforms as well. Or is it Windows specific?

      Yes [slashdot.org] and no respectively. It only affects Adobe Reader. All other PDF software is unaffected, I believe.

      • by Lumpy (12016)

        and installing and using adobe reader speedup or adobe reader lite that has all the bloat stripped out solves the problem as well.

        Honestly Adobe reader went downhill ever since 5.1 was released... 5.0 was the best after that they only have added in garbage.

        • by Ilgaz (86384)

          I will take the risk and tell it. Adobe Reader 9 is one of the best performing and low CPU using PDF readers out there and I am writing this from a 1.42 Ghz G4 Mac Mini with 1G RAM installed.

          It is real sad that because of the bureaucrats and some idiots at Adobe, one of the most serious multi platform security vulnerabilities happened just when Adobe Reader was heading right direction both in performance and UI wise.

          I know what you mean by version 5 and I actually have it installed in a Quad G5 (via Tiger's

    • Re: (Score:3, Insightful)

      by Aladrin (926209)

      "And why the fsck does a freakin' DOCUMENT have scripting in it? I can understand form elements but not something akin to shell scripting."

      Can I assume that you're upset about HTML having all this stupid Javascript stuff, too? I mean, it's just for displaying and linking to information. It doesn't need 'something akin to shell scripting'.

      • Re: (Score:3, Interesting)

        by mmontour (2208)

        Can I assume that you're upset about HTML having all this stupid Javascript stuff, too?

        I can't speak for the original poster, but I'm certainly happier since I installed the NoScript extension in Firefox. Slashdot was one of the main reasons that I installed it, as there was some script on the front page that used to freeze my browser for a few seconds for no good reason.

        In a PDF "document" I sure as hell don't want any active scripts beyond the ones that are needed to generate the pixels I'm looking at. I can see a use for interactive forms and similar scripted things, but they should not be

  • by Shaman (1148)

    Use Foxit! Reader on Windows and something else on other operating systems, such as Okular.

    • Re: (Score:3, Funny)

      by symes (835608)
      Sod it - I'm going back to plain text and ascii art.
    • by jbn-o (555068)

      Jumping from one uninspectable, unmodifiable proprietary PDF reader to another is not wise. Better to run more free software, not less. Pick a free software PDF reader for all of your computers so you can see what it will do, change it to meet your needs, and share your improvements with the community. Better still, run a free software OS so you can enjoy the benefits of free software for all of your programs not just a PDF reader.

      • by Thiez (1281866)

        > Jumping from one uninspectable, unmodifiable proprietary PDF reader to another is not wise.

        I don't have the time, the knowledge, and the motivation to inspect and modify my PDF reader. Few people do.

        > Pick a free software PDF reader for all of your computers so you can see what it will do, change it to meet your needs, and share your improvements with the community.

        Keep in mind that the vast majority is not going to read the source code. 'You can read the source' is irrelevant 99% of the time; if I

      • by Ilgaz (86384)

        If one has at least KDE shared libs installed, kpdf could be a nice full feature open source replacement. I know there are lots of different alternatives exist but I was amazed by the performance and display quality of kpdf on OS X (installed via fink). We already have state of art quartz pdf renderer and it is hard to impress people on this platform.

  • by Gothmolly (148874) on Thursday March 05, 2009 @09:59AM (#27076527)

    Executable code should not be embedded in documents, the format should not allow it, and document readers should not execute code.

    How fscking hard is this?

    • Executable code should not be embedded in documents, the format should not allow it, and document readers should not execute code.

      Sorry, but you lost this fight a long time ago. Even emacs supports embedded executable code in documents.

      • by DoofusOfDeath (636671) on Thursday March 05, 2009 @10:21AM (#27076739)

        Sorry, but you lost this fight a long time ago. Even emacs supports embedded executable code in documents.

        And don't forget Postscritpt. And LaTeX.

        At the ICFP08 conference, there was a student who'd written an autonomous (simulated) robot controller, in LaTeX.

        • You mean, even LaTeX is not safe against Viruses? What should we use then? Or should we just abstain from writing documents altogether...
          • Re: (Score:3, Funny)

            by Waffle Iron (339739)

            You mean, even LaTeX is not safe against Viruses? What should we use then?

            LaMbSkIn?

            • That's indeed a more natural form of Word processing. Whether it is better at protecting against viruses than LaTeX is open for debate.
        • by steelfood (895457)

          Just because you can put executable code in a document, doesn't mean the document reader should execute it.

          • Just because you can put executable code in a document, doesn't mean the document reader should execute it.

            True, but at least with LaTeX and Postscript, some code must be executed just to render the document. So for some document formats, precluding all document code execution makes the rendering program useless.

      • by Gothmolly (148874)

        No, the yutzes who allowed emacs to execute code lost the fight.

        • Re: (Score:3, Interesting)

          by johnsonav (1098915)

          No, the fight was lost when we first decided to use ones and zeros to represent both code and data. There is simply no significant difference between the two. Indeed, you can't have data which does not alter the execution of code.

          • by V!NCENT (1105021)
            No, the fight was lost when people started going online, or even before that; share digital information from and to a device that computes information.
    • by myxiplx (906307)

      And if you really, really have to allow some kind of code in documents, for the love of all that's holy, don't allow anything to execute by just hovering your mouse over it.

      I don't know who to shout at more for this. Adobe for having such a stupid bug. Or Microsoft for allowing people to modify windows explorer in such an unsafe way.

      If you're going to allow extensions to such a fundamental part of the OS, surely they should be sandboxed and isolated, to guard against exactly this kind of thing?

    • by ledow (319597)

      Remember WMF?

      A graphics file format that basically relied on calling Windows primitive functions to draw itself and (for a long time) allowed arbitrary binary code inside them to be executed whenever they were displayed?

    • by jonaskoelker (922170) <jonaskoelker@gn u . org> on Thursday March 05, 2009 @12:02PM (#27077921) Homepage

      Executable code should not be embedded in documents

      Why not? Seriously, why not?

      The real problem, IMNSHO, is not that there's code, but that the code is allowed to do other things than to just compute stuff.

      I'm not really sure why you'd want documents to contain code, but I can imagine someone might want to say "the first 20 primes are 2, 3, ..." and have the computation done at "run"-time. Or at least, something else interesting that exceeds the capabilities of easily analyzable language classes (regular, context-free).

      The badness happens when document-embedded code can read my file system, write to my file system, run other programs that are outside its own sandbox, or talk to others via the network.

      (I think the Java security model tried to do approximately this.)

      As a way to attack parts of the problem, perhaps document readers should just run the format interpretation code in a process which drops all unnecessary capabilities?

      At least in principle, being able to compute doesn't mean being able to violate your security concerns.

      In haskell terms, none of the code inside a document should have the type `IO a', and then you'd be safe (assuming of course that unsafePerformIO and the like didn't exist).

  • I caught my first ever virus using Firefox thanks to some sort of PDF exploit. Was browsing normally, got a popup that flashed up for a brief second and I saw it was a PDF of sorts. My hdd started thrashing and my anti-virus started giving me dozens of warnings.

    Managed to make sure there was no trace of the virus on my system but it serves as a warning to people who assume Firefox is perfectly safe providing you are careful.

    • Re:PDF and Viruses (Score:4, Informative)

      by John Hasler (414242) on Thursday March 05, 2009 @10:10AM (#27076631) Homepage

      If you allowed a popup to occur you were not being careful.

      • by MadKeithV (102058)
        If you allowed a PDF to occur you weren't being careful either. I've set noscript to block PDF until clicked, all the time.
      • Re: (Score:3, Informative)

        by Thiez (1281866)

        Does it matter? GP could also have have been tricked to click a link that leads to the same page as the popup. Disallowing popups would not have saved him in that situation. The problem is not allowing popups, the problem is that his browser was not secure.

    • Best way to prevent these is to disable the PDF plugin that allows for automatically opening documents in the browser.
    • by Renraku (518261)

      This type of exploit has been around for a while, actually.

      I had certain common malware installed because a banner on a popular site carried a PDF that I didn't even have to click on.

    • by V!NCENT (1105021)
      If I [you] put a timed bomb [PDF] inside of your car [FireFox] then is the model of your car [Firefox] per definition not safe?
      • by abigsmurf (919188)

        You'd like to hope if you put unleaded petrol in a diesel car that it wouldn't explode in a huge fireball causing you a painful death.

  • by Morris Thorpe (762715) on Thursday March 05, 2009 @10:11AM (#27076643)

    I stopped using Reader long ago - not because of vulnerabilities, but because it was so slow and bloated and it installed stuff I did not want.

    I've been using Sumatra for a very long time and it has done well by me (http://blog.kowalczyk.info/software/sumatrapdf/index.html)
    Download the zip file for a no-install, single-file exe. Minimalistic but more than enough for 90 percent of pdf's I ever need to open (the rest, I open through Google docs.)

  • Whoa (Score:5, Interesting)

    by ledow (319597) on Thursday March 05, 2009 @10:27AM (#27076785) Homepage

    So when I click once on a file, executable code is run from the program associated with that file?
    When I view a file in Thumbnail mode, executable code is run from the program associated with that file?
    When I hover to get a filename, executable code is run from the program associated with that file?
    How many other daft, unnecessary executions of programs are there?

    Not surprising because this is Windows we are talking about but holy crap - what a way to design a file browser / operating system. The problem here is NOT Adobe, or PDF or anything else, the problem is terminally-shit operating system and file browser design - executing entire programs to perform unnecessary tasks (e.g. add a column to explorer, generate a small bitmap, provide some hover-text). My next question is: in which user context is that code run? Please tell me that it is AT MOST the current user and not SYSTEM or some other built-in account. This sort of stuff should be found by a series of regexp's (which the program supplies) on the file data, NOT letting the program run just to tell you that Fred wrote this particular file. Then you can execute those to your heart's content in a secured area that benefits from global security upgrades if anyone finds a way to compromise the regexp. A bit like using "file" on *nix... just supply it with a regexp for a particular file extension and let the regexp extract the date, time, author, etc. in a safe environment.

    No. Not MS. Every bit of freeware, every crappy game, anything that associates itself with a filename (which is almost impossible to stop on a home PC, only possible to detect/undo if you know how) is constantly run everything you view explorer in Thumbnail mode, or hover, or click on a file.

    It reminds me of a little bit of trickery I did back in school... given the task to "hack the school network" on a computer course, we managed it within minutes by running exploit programs. Being the brightest IT student back then, I was asked to help prevent a repeat... my solution was to misuse the Windows 3.1 file associations in the global WIN.INI so that .exe, .com, .bat, .pif were associated with a tiny program that everyone had network access to. Anytime anyone ran a program, it was sent as a command-line parameter to this "security program" instead.

    From there, the *program* would decide if the requested executable was actually valid and allowed (i.e. correct path, correct hash, put there by the network staff etc.) and if so, it executed it. If not, it popped up a message to deny access. It was surprisingly secure, given the state of multi-user networked Windows 3.1 back then, and even from an Administrator account we found it virtually impossible to get around provided other, more ordinary security was in place on WIN.INI (we even had to reset the admin account once because it managed to lock us out when we misconfigured it... fortunately, we had spare, unaffected accounts because we couldn't find any practical way around it!). Back then, though, you had to double-click, or File... Run... or whatever to make a program execute from the Windows shell... it even caught program execution from within Word macros that the network manager had been fighting for months ("A=Shell("Z:\game.exe")")... though not from a DOS shell, IIRC but we already had DOS Shells disabled by preventing the command.com from running except in specific contexts!

    How easy it would be to write a piece of malicious code that associated itself with all executable file types and executed BEFORE the executable... so even when you try to run Remove_Sasser.exe or Install_Antivirus.exe, it would be intercepting and denying those requests. Obviously this has always been possible to do when somebody double-clicked on a executable, but now the associated program gets run just by LOOKING at any file with the right filetype. Make that executable a self-replicating virus and it's basically unstoppable (Yes, if you're

    • Re: (Score:3, Informative)

      by clone53421 (1310749)

      Not surprising because this is Windows we are talking about but holy crap - what a way to design a file browser / operating system. The problem here is NOT Adobe, or PDF or anything else, the problem is terminally-shit operating system and file browser design - executing entire programs to perform unnecessary tasks (e.g. add a column to explorer, generate a small bitmap, provide some hover-text).

      That's strange, because the last time I booted up a Kubuntu live cd, the file explorer created preview bitmaps for all the PDFs in any folder I opened.

      • Re: (Score:3, Informative)

        by ledow (319597)

        What did it use to create those previews? Adobe Acrobat Reader (the associated program for that particular user on that particular system) or a program that has been specified specifically for that purpose? Or even it's own internal renderer? I don't think it's sitting there loading up Acrobat Reader for Linux for every thumbnail, somehow, which is apparently what Windows does. I think you might find that konqueror internally decides to use libpoppler, no matter what file is associated with PDF mimetype

        • Granted it's not loading up Adobe Reader (at least, we both hope it isn't, because that would be immensely stupid). It's still linking in another library, which was essentially what you were ranting against. If the library is buggy, you could introduce security holes.

          • ...and I don't know yea or nay, but the relevant question here is, does Konqueror allow installed applications to provide previews for "new" mimetypes? If the PDF preview library is "secure" and it's impossible to extend the preview feature to add libraries that preview new file types, then it's pretty secure. However, you've lost the flexibility of previewing new file types, probably unless someone updates Konqueror itself, since it doesn't trust your library.

    • Re: (Score:3, Informative)

      by Rary (566291)

      Your +4 Interesting (at the time I'm writing this) rant against Microsoft completely fails to take into account the fact that this vulnerability is not limited to Windows, but in fact affects all platforms.

      Now, please write your rant 100 times on the blackboard, substituting "Linux" for "Windows", then write it 100 times more substituting "OSX" for "Windows".

      • by ledow (319597)

        Actually, I'll think your find that *this* vulnerability affects only Adobe products but I haven't seen any mention of anything saying that non-Windows platforms are vulnerable... I just checked CVE, secunia, etc. and the only disassembly I can find of it is for Windows. I'm not saying that bug doesn't exist on other platforms, but that's not my point... my point is that it's executing a program with (at least) user privileges to draw an icon, or a tooltip. WHY?

        I haven't seen another platform where Adobe

        • Re: (Score:3, Informative)

          by Rary (566291)

          The Adobe advisory [adobe.com] indicates that it affects all platforms, and others in this thread have also pointed it out (some with links).

          The second link [didierstevens.com] in the summary also explains that the preview functionality is added through a shell extension installed by Adobe, as opposed to default Windows functionality, although obviously Windows provides the API to make it possible. Similar functionality exists in the Linux and OSX worlds.

          This is not the fault of bad Windows design. This is the fault of unnecessary preview

          • Yes, but do other operating systems use an Adobe shell extension to preview the file, or do they use an internal library? If you open the file with Adobe Reader, then sure, you're at risk. However, if the Adobe shell extension is opening the file to create the preview, you can execute the payload just by opening the folder containing the malicious PDF, whereas if a library that doesn't have this security flaw is used to preview the file, you'd have to actually open the file in Adobe Reader before it could d

  • Hold on (Score:2, Funny)

    by rockbottoms (1393173)
    My Adobe PDF is loading. I'll let you know if it's safe or not in about 5 minutes
  • by gzipped_tar (1151931) on Thursday March 05, 2009 @10:57AM (#27077083) Journal

    One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.

    First, there's no fundamental difference between "code" and "data". It's all binary blob. The .text section in any of your ELF programs is understood as "executable code" by the interpreter (ld.so) but as plain document by objdump. The point is to always interpret the data as how it is intended to be used, and this is hard. This Adobe fiasco is caused by a buffer overflow in the program (which is not even in a function responsible for JavaScript). Buffer overflows are known to be useful for exploits because they allow an attacker to "cheat" the program so that it misinterprets what intended to be document data as executable code. It just happens that the flawed code can be attacked with greater rate of success using JavaScript. (According to this security advisory http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219 [shadowserver.org])

    Second, embedding executable code in a document is not inherently evil or stupid. It's just an idea that can be either utilized or abused, varying from implementation to implementation. I don't like scripting in PDF either but not for the reason of its alleged insecure nature, but because it bloats the file format.

    Just my 2c..

    • by MrNemesis (587188)

      One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.

      TBH, I think you're more in agreement with them than you think - people are up in arms about executable code in documents *because* it's often so poorly implemented and the parsers have problems with it, resulting in vuln after vuln. I'm not against executable code in documents myself, per se - but I'm wary of anything that makes extensive use of it simply because it's been such a huge attack vect

    • by mmontour (2208)

      First, there's no fundamental difference between "code" and "data". It's all binary blob

      That's true on a von Neumann architecture. A Harvard architecture [wikipedia.org] CPU (used in some microcontrollers) has a stricter separation between the two concepts.

  • by dpbsmith (263124)

    I just don't get it. What exactly is so difficult about the concept of a file format containing data only, that is passively rendered by an application?

    In fact, wasn't passive rendering the whole reason from moving from PostScript to PDF?

    Is it that hard to review code and make sure that the interpretation of the format doesn't trigger any conditional branches that cause execution of anything but fixed, static, read-only code within the application? It seems to me you could use a modified version of one of t

  • Right now I have to use Adobe Acrobat Professional, because I have a TabletPC, and need from time to time to highlight, or annotate, PDFs. Do you know a better alternative? Thanks a lot
    • Jarnal [dklevine.com]. It's a bit obtuse (you'll need to remove the default lined background, then open the PDF you're annotating as a background image – which does mean you can't edit the text, unfortunately), but then, it is free. It's done what I wanted, more or less.

      If all you want to do is highlight (there are several pen tools which can be used to highlight or draw) or annotate (there's also a text tool, which as I mentioned can't edit the existing text in the PDF), it'll probably be adequate.

    • by B5_geek (638928)

      E-Copy.

      It is not free, but it is an excellent work-flow tool (that uses PDF as the framework).

  • If they infect enough machines, perhaps something will finally be done about it.

  • As all companies in this economic disaster you will layoff people. I am sure you know which department to layoff and while on it, don't forget the OS X guys which manages to keep Debugger() symbols in World's most popular plugin, Flash.

    Yes OS X people and especially Webkit/Browser developers, that mysterious ''Debugger() was called!'' in system.log comes from Flash 10 plugin because idiots forgot to remove debug symbols! That is a bug which wasn't fixed for months and even in recent security update release

  • Considering that Adobe still hasn't fixed the broken thumbnails in 64-bit environments (as of Acrobat 9 with current updates), this exploit seems to affect 32-bit systems. I haven't yet seen working .pdf thumbnails in 64-bit Vista (or Windows 7 Beta, for that matter).
  • To all of those who don't think they want to see "executable code" in a PDF document....

    How else would you implement a typesetting language? There is a big problem with simple bitmapped fonts, they don't scale, no sharp edges unless the scale of the bitmap exactly matches the screen resolution. So we need __instructions__ on how to draw the characters. Also those instructions change if the characters is large or small relative to the screen resolution. You can't make goos looking documents without some

  • I can't seep to find this 'Windows Explorer Shell' thing in aptitude or synaptic.

Brain off-line, please wait.

Working...