Bug In Acrobat Rendering

I think I found an error in how Acrobat renders textures. I have a U3D file that opens correctly in another rendering program that I knows uses the Intel U3D toolkit. (http://sourceforge.net/projects/u3d/)
The correct rendering of my file looks like this:
http://img23.imageshack.us/img23/7243/correctrenderingofacrob.png
Acrobat shows this:
http://img509.imageshack.us/img509/716/acrobatbugm.png
Is this a known bug?

Dear William,
may I ask you to take a look at http://forums.adobe.com/thread/299672
and the lineset problem reported there (per vertex colors documented,
but do not work, materials are said not to work but do).
If it is not a known/acknowledged bug I am ready to present test cases.
Is it possible to update U3DElements.pdf with information on fixes
introduced in Acrobat 9.0, 9.1? Or at least fix what looks like copy-paste errors
and is described in my post "U3D support limitations" mentioned above?
        Sincerely, Michail

Similar Messages

  • EPS to PDF: Smooth Shades, Bug in Acrobat?

    Hello!
    I encountered a really weird feature/bug in Acrobat.
    I have a very simple EPS file which draws 2 x 5 = 10 adjacing black squares. (EPS file below and attached)
    When I drag it into Acrobat 8.1.5 and save it as PDF, and then try to open this PDF in Illustrator, Illustrator says: [German] "Eine unbekannte Schattierungsart wurde gefunden." which might be in [English]: "An unknown shading type was found."
    And then the big regtangle (which was the 10 squares before) cannot be edited in Illustrator because this object is [German] "Grafik aus Drittprogramm" which might be in [English]: "Graphics from third party software".
    The fact that Acrobat makes a large rectangle out of the 10 squares, is not very uncommon. But why does Acrobat not leave the color black but changes it into a smooth shade (which runs from black to black)???
    (I know that I can disable the smooth shade feature in Acrobat. But still: there is a bug in Acrobat that reconizes an object with one unique color as a smooth shade!)
    %!PS-Adobe-2.0 EPSF-3.0
    %%BoundingBox: 0 0 10 5
    %%LanguageLevel: 2
    %%EndComments
    %%Page: 1 1
    save gsave
    /Rectangle {
    1 index 0 rlineto
    0 exch rlineto
    neg 0 rlineto
    closepath
    } def
    /N { newpath } def
    /Q { moveto 1 1 neg Rectangle fill } def
    0 setgray
    N 1 2 Q
    N 1 3 Q
    N 2 2 Q
    N 2 3 Q
    N 3 2 Q
    N 3 3 Q
    N 4 2 Q
    N 4 3 Q
    N 5 2 Q
    N 5 3 Q
    grestore restore

    Are you sure didn't have the Shift key down at the same time as you pressed Cmd and the + (plus) key?
    Cmd-Shift-plus and Cmd-Shift-minus are the shortcuts for rotate clockwise and counterclockwise.
    For me, with Acrobat X 10.1.1 on Lion Mac OS X 10.7.2, Cmd-plus and Cmd-minus are working fine for zooming in and zooming out.

  • BUG in acrobat 10.1.1 for mac

    i found a bug in acrobat pro 10.1.1 running on mac osx 10.7.2
    whenever i try to zoom by using the "Cmd" + "+" key, the pdf document is rotated 90 degree clockwise instead of zoomin the page like in previous updates (10.0 - 10.1)
    please fix this bug in the next update adobe.
    thanks!

    Are you sure didn't have the Shift key down at the same time as you pressed Cmd and the + (plus) key?
    Cmd-Shift-plus and Cmd-Shift-minus are the shortcuts for rotate clockwise and counterclockwise.
    For me, with Acrobat X 10.1.1 on Lion Mac OS X 10.7.2, Cmd-plus and Cmd-minus are working fine for zooming in and zooming out.

  • Problem with saving optimized PDF 900dpi, image is partially repeated... is this a bug in Acrobat Pro 10.1.10?

    I try to save a bigformat PDF file (1.4 Gb) with save optimize PDF. Hereby I send some screendumps to make this stuf clear. See screen after at the right; Is this problem a bug in Acrobat or due to Hardware problems? I use the newest Mac Pro with 32 Gb Ram.
    txs for rsponce!! grz. Paul

    Hello Paul,
    I am unable to replicate the issue.
    I am send you a Private message to share the sample file with me.
    Please share your file along with Steps to Reproduce the issue.
    Regards,
    Anoop

  • Bug in java2D rendering without AA

    I think I found a bug in java2D rendering when not using AA, shapes move up and to the left when alpha other than 1 is used.
    I will file a bug report at some point, but I want to talk about it here first.
    To reproduce:
    g2.drawLine(0,0,10,10);
    g2.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, alpha));
    g2.drawLine(0,0,10,10);lines will not be the same.
    However there are several rendering hints that have an effect on the bug, so I created a test program to facilitate more complete testing.
    [here it is.|http://www.mediafire.com/file/nunninzinot/J2Dbug.jar]
    If any one could run it for me and tell me what happens on what os/jvm I would be most grateful.
    The source is also in the jar.
    I have tested the following os/jvm combos, problem shows up on all of them.
    vista32 sun 1.6.0.15_0 or something.
    winxp32 sun don't know.
    ubuntu64 OpenJDK 64-Bit Server VM 1.6.0_0.

    Alright after trying hundreds of combinations and restarting between several of them I've discovered that molecule will work on my card if at least one of the following are met:
    1. -wireframe is specified
    2. -no-labels is specified
    In molecule.c the draw_labels function disables lighting on line 1346 if wireframe is off and enables it again on 1415. Something about turning lighting on and off too quickly might hang my card.

  • Images with Transparency Cause Rendering Bug in Acrobat

    Try this at home: Export a file containing an image with transparency to PDF and open it in Acrobat (any platform, any recent version): the page containing the image will have all text rendered in what looks like bold or faux bold, depending on the font. The document looks fine in Preview and printed (even from Acrobat).
    Can anyone else reproduce this? I get this behavior consistently.

    Hi bdepaepe, I've had a look and I believe I have experienced the error you mean and solved it.
    The reason this occurs some of the time, but not always is because the source code is not the same each time, as the adverts change every refresh. The error only happens when two of the < div> tags of class 'banneritem' which are on top of each other have a height of 84px each as opposed to 80px (although even if this is the case the rendering issue doesn't always happen).
    The reason that some of the 'banneritem' < div> tags have a height of 84px is because inside them there is an <a> tag which contains an < img> tag, and the <a> tag has not been set to 'display: block;'. <a> tags are inline elements by default, so shouldn't be used to hold block level elements such as images unless the styles for the <a> tag include 'display: block;'.

  • Color Shift Happening When Exporting - Bug in Acrobat Export?

    Hi, we are using InDesign CS3 and trying to output a file to send to a printer. We are desiring to have all colors converted to the printer's CMYK color space upon exporting (they sent us their ICC profile).
    But we are getting a bizarre bug that I cannot figure out. It seems like it's actually a software bug, not an issue with settings. I'll try to describe the issue here:
    Upon using 'Convert to Destination (Preserver Numbers or Not)' in the PDF export dialog in InDesign (using PDF/X-4 setting), using the 'Document CMYK' profile, there is a shift in color for 1 particular element. We have a grayscale image of a bunch of dots (black dots on solid white background) that is placed in a frame in InDesign. This image is 'colorized' in InDesign by setting an image color and a frame color (the image color appears as the 'foreground' and the frame color is the 'background'). We've been doing this all the way back to the Quark days (many years). But if the 'background/frame' color is a combination of C+M+Y (with no black), the Magenta and Yellow values are shifted to the Yellow and Black channels (for example - 52c, 5m, 10y, 0k becomes 52c, 0m, 5y, 10k).
    I have never run into this before, and we've run this job with the same element many times now over the last couple years. But I have always used 'No Color Conversion' in my PDFs in the past. So it has something to do with the 'conversion'.
    So far I've tried:
    - Creating new document with just the single element, also created from scratch. So it's not an error in the file.
    - Starting with different profiles (to make sure the profile wasn't corrupt).
    - Choosing 'Preserve Numbers' or not when outputting PDF.
    - All sorts of color combinations. It also appears that if there is black in the color, this value gets shifted to the magenta channel, then the magenta & yellow bump down.
    - Checked the grayscale image to make sure it was flat, and using pure black & white colors. It is.
    I've also tried printing to Distiller (we have Acrobat 8 Pro), but the settings are a lot different here so I'm not sure if I set it up properly. I made a duplicate of the default PDFX3 2002 profile, then edited the color settings to 'Convert Everything to CMYK' and set our printer's profile as the CMYK Color Space. But images are converted to 'DeviceCMYK' and not the profile I put.
    - ANYBODY have any ideas or even know where I would start???
    THANKS. This job needs to go out, but I'm also trying to get a solid workflow down for the future.

    Looks like the issue in the CM thread.
    I'm trying to replicate the issue but haven't done it yet. Still grasping at straws
    1. Did the ID doc ever undergo Convert to Profile?
    2. In Swatch Panel do "Add unnamed colors". Make sure the grayscale is colored with swatches, not colors created in the Color Picker
    3. Do the color values in the swatches have crazy decimal values? Is the color mode of the swatches CMYK?
    4. What format are the grayscale links - TIFF or PSD?
    5. Make certain they are links, not embedded (I'm sure they are links though)
    6. The colorization - are there tints applied to the object colors, or are they 100%?

  • Setting trim box bug in Acrobat Pro 7 & 8 - try it...

    I have filed this bug a few times with Adobe over the past months but there doesn't seem to be any movement. I'd download the trial of Acrobat 9 Pro to check but alas us Mac users are not deemed worthy of that.
    I implore anyone who can to try out the following:
    - Open up an existing PDF or create a new, blank one. Zoom out to a point where you get a good amount of "no-man's land" gray around your document.
    - Go to Document->Crop Pages... and pick "trim box" from the drop down menu.
    Now start moving the right-hand constraint of the trim box using the "up" arrow widget and see what happens in the main document window. For me and the users that I support, the guide that represents the right-hand trim box constraint will start coming in from the right-most side of the document window, that is, inside the gray out-of-bounds area. In addition to the guide being in the wrong place it also doesn't get redrawn every time the right-hand margin is moved by the standard .125" step by clicking the "up" or "down" widget. As a result there will be a whole mess of black vertical guides left on the screen, obscuring the actual position of the guide regardless of whether or not it is placed on the screen in accordance to the right-hand trim box constraint setting. Similarly, the main document can be zoomed in to fit to window but the guide will still be drawn incorrectly and exhibit the same "ghosting".
    All of this has remained the same between versions 8.0 and 8.1.2 of Acrobat Pro and in one of my discussions with an Adobe tech rep who was testing it on his side I was told it also exists in Acrobat Pro 7. It is an issue because the small preview window in the Crop Pages window is not very useful when working with large document dimensions that need precise trimming adjustments beyond a standard eight or quarter inch all around.
    Hopefully someone else can confirm this issue while I try to find out whether Acrobat 9 still exhibits the same behavior.
    Thanks.

    This has been a problem since version 8 on the mac. Acrobat 7 on the mac worked fine with the right side trim but not on the PC.
    We are still having this problem with Acrobat 9.4.0 on the Mac & PC.
    This has now been an issue for 2 versions of Acrobat Pro.(8 & 9)
    Being in Pre Press and having to constantly set the trim for jobs, this is now taking up too much time and costing money.
    Please fix this Adobe.
    and on another note. how hard would it be to display the trim (if set) next to where the page size is?
    If the trim is set it should display it! why should we have to go to document/crop pages>trim.
    Im in a busy Pre Press Dept and the amount of times you have to check a trim size is stupid.
    I always set prefs to display crop / trim / and bleed boxes and this helps but it should display it if its set.
    Thanks
    Hope this is resolved soon.

  • Another BUG in Acrobat 9.4.5 -- Find doesn't work

    I made the mistake of updating to the latest version Acrobat 9.4.5, and discovered that the Find feature doesn't work right.  For example, I enter a word to search in the "Find" box, and click return.  In past versions, the PDF would jump to the first instance of the term or phrase and highlight the word.  Now, the PDF jumps to the page, but doesn't highlight the word!  So... I'm stuck reading through text to find the word, which is a lot of extra work and time that I don't have. This is a critical problem because I search documents for terms all of the time in my job.  
    I've found one workaround that isn't very satisfactory, but it is better than nothing.  Instead of using "Find Next in PDF", I use "Open Full Acrobat Search" which is a command off the Find pull-down menu.  This command opens up a separate window, which is annoying because it disappears behind the document if you need to page through the PDF file. However, if I do the search, it shows all of the instances in a pane in the context of the sentence where it appears.  Then, if I click on the instance of the word in this pane twice (Yes, TWICE), it will highlight the word in the PDF. You cannot use the Find Next button as you could in previous versions, because this function will not highlight the word.  Anyway, given there are other bugs in this release that I've read about in this forum, I'll most likely just go back to the previous version and completely disable the automatic update feature in Acrobat.  I wish going back was a quick process, but I don't think it is.
    I'm also going to tell everyone in my circle of friends to avoid automatically updating Adobe Acrobat in the future. Adobe obviously doesn't test the software well. Wish I could charge Adobe for the time and frustration they've caused me!

    Brianwrx,
         The Acrobat 9.4.5 update bugs where the first "hit" on each page is not highlighted when doing a Find/Search and no longer being able to use Shift & Ctrl on the Pages pane thumbnails to multi-select and move/delete pages are well reported by many to have been introduced coincident with the Acrobat 9.4.5 release and not a MS Windows update.  I'm not sure what is going on with your 9.0.0 Pro Extended.
         For seasoned Adobe to break such commonly used features in Acrobat 9, never have regression tested these basic functions given the 3 month (or longer) release cycle, and not have broke it in Acrobat X doesn't reflect well on their development/test process.  Then, there are web forum recommendations prodding to upgrade to Acrobat X -- which completely changed the User Interface and will result in significant loss of productivity while bridging the learning curve and dealing with new functional/compatibility problems.  Furthermore, it is something how OCR Suspects are never found/flagged in Acrobat 9, and then were finally fixed in Acrobat X (forcing the need for a paid upgrade to get a bug fix and have to relearn the interface to boot).   
         Adobe's poor quality 9.4.5 release update does me more harm than good when considering other settings to improve Acrobat security (turning off Java-Script, not automatically trusting sites from the Win OS security zones, and not allowing the opening of non-PDF file attachments with external applications under the Edit menu - Preferences).  Adobe has made no official commitment to fix its bugs or provide a release date in the 10+ weeks since the awful 9.4.5 code was thrown over the fence to unsuspecting auto-update customers without any practical/simple way to back it off to 9.4.4 -- even though in all probability it will take the programmer one day each to fix the bugs with some additional time to test/release).  It is interesting that there have been no critical Acrobat security issues (as evidenced by no Out-Of-Cycle releases since 9.4.5), which should mean their programmers have more time to fix these bugs and restore stable functionality in 9.4.6.  As for "not being able to use Shift & Ctrl directly on the Pages pane thumbnails to move pages" (another 9.4.5 bug), the circumvention to drag a window around a group of pages, hold down Shift, and drag a window around a second group of pages should be further clarified with the following: Once your blue highlighted contiguous/non-contiguous pages selection is made, be sure to drag a thumbnail graphic directly to move the selection and don't try to drag the blue shaded perimeter area (which results in clearing the blue highlighting).  This does provide a decent circumvention for that bug -- as compared to the cumbersome "Full Acrobat Search - Advanced Search Options - double-clicking each Result line" circumvention for the Find/Search first "hit" non-highlighting bug.  I implore Adobe to listen to your customers and please take a "do no harm" conservative approach to updates/enhancements in the future.

  • Bug in Acrobat 9.4.1

    A recent release of Acrobat caused disruptive  in browsers - each time a PDF was opened, Acrobat 'prepared' the document. This is a time wasting process which should be selectable for those few people who need the functionality. Based on some research, this behavior can be circumvented by removing Accessibility.api from the Acrobat/plug-ins folder. However, this results in a bug: Once removed, Edit->Preferences no longer functions.
    Is there some other approach to turning off the unneeded accessibility functionality without breaking Edit->Preferences?

    Try changing the following preference:
    Edit > Preferences... > Reading
    Reading Order: "Use reading order in raw print stream".
    Page vs Document: "Only read the currently visible pages".

  • Two bugs in Acrobat 9?

    I'm trying out a Document in Acrobat 9. I found two apparent bugs.
    On my PowerBook 17" I have installed correct Driver for my Printer a HP DJ 990cse. However when I go to set as default printer inside Page Setup within Acrobat 9 the is no indication of a printer. Yet when I go elsewhere such PDF Optimizer> advanced it shows the printer. Note I use printer Plugged into my Airport Express. Acrobat 8 has no problem with this setup.
    Problem two: In the document I noticed a defect in one line with the letter "g" and attempted to use touch up text to retype it to see if I could repair the defect. well when I did the text drop a point or so below the line and completely messed up anything in the box.
    My PowerBook 17 uses a display of 1400x900
    IN suggestions?

    Nemuri13 wrote:
     Gentlemen - the workaround is to open Acrobat first. Then do a file > Open to open the file in Acrobat. If you do this then you should see your printers in the Page Setup. If you double-click on the PDF to open it in Acrobat then you will NOT see your printers. This seems to affect only 10.4.11 and not any version of 10.5. Good Luck!
    For some reason this thread just showed up on new Forum System.
    Anyway I tried your work around. Had no affect.

  • Bug in Acrobat Reader 8 & 9? "Actual size" not actual size

    When I choose to view a PDF in "actual size" using Adobe Acrobat Reader 8 or 9, it is NOT actual size.  Under Acrobat Reader 7, it WAS actual size.
    For example, if I go to the properties of the document and find out that it is supposed to be an 8.5 x 11 document, the document on screen is not 8.5 x 11.
    This used to work under Acrobat 7, but doesn't work under Acrobat 8 or 9.  It used to be that you could hold an 8.5 x 11 piece of paper up to your monitor and the size of the image on screen was exactly 8.5 x 11, but now if I do the same thing, the size on the monitor does not match the actual size of the paper.
    Is this a bug or something else?

    The screen size is 17" and the current resolution is 1024 x 1280 (it is in "portrait" mode), but it happens at every resolution I've tested.

  • Bug in Acrobat Reader Plugin for FF?

    Hi,
    i use a web application which pulls pdf reports from a server by http-post requests, so parameters are transmitted in the requests-body.
    As a viewer i do use Acrobat Reader Plugin, most recent release with FF 3.0.3 on Windows XP pro.
    So due of the http-post requests the requested url remains always the same for every report.
    The problem:
    In case of two reports having the same content-length, the former requested report is displayed as the result of the last request, though the content is different.
    The effect could be reproduced.
    Obviously the plugin cant distinguish the reports. With Acrobat Reader as the Viewer and with IE and Adobe AddOn all reports are displayed correct.
    Beside the http-post implmentation may not be the best way to do this, is this a bug or mishandling by the user.
    Regards
    Chris

    Post your question in the forum for Adobe Reader.

  • [BUG]: af:commandButton rendered with requestScope variable doesn't work

    This took me two days to figure out, and I wonder if it is a bug:
    I have a page that can be navigated to on two occassions, let's call them "left" and "right". I want the page to know what side I came from, so I set a requestScope variable on the buttons that navigate to this page, a bit like this:
    <af:commandButton action="toPage">
      <af:setActionListener from="left" to="#{requestScope.sideFrom}"/>
    </af:commandButton>I have two buttons on the page, one is to navigate back to the left and one to navigate back to the right. Only one is rendered, depending on the requestScope.sideFrom variable.
    One says rendered="#{requestScope.sideFrom eq 'left'}" and the other says rendered="#{!requestScope.sideFrom eq 'left'}"
    Only one button works, namely the one for which the rendered property evaluates to true <b>when the button is pressed</b>!! My requestScoped variable doesn't exist anymore when I press the button to navigate back so it's behavior is changed. How weird is that?
    Should I file a bug?
    I refuse to make it a sessionScoped variable and change it back with the return buttons Imho this is what requestScope is for.
    I am on JDeveloper 11.1.1.6

    Wendy,
    To amplify what Timo rightly says: as JSF goes through its merry lifecycle, one of the steps is to rebuild the component tree in memory. When you use the rendered property, that particular component is not in the component tree - it's as if it doesn't even exist according to JSF. Then, when it comes time to deal with events, the event isn't seen or is ignored (I don't know which) because JSF doesn't think that component is present. As Timo also rightly says - this behaviour is why the "visible" attribute was created.
    John

  • Bugs in GPU renders in Premiere CC 2014

    I have two UltraKey effects applied to a clip (one of them with a mask for special cleanup on a person's hair).
    With GPU turned on, in a rendered video, the person's hair has a flickering halo, like the second UltraKey is alternating between being on and off.
    With GPU turned off, the video is rendered as expected with no flicker.
    As in previous versions of Premiere, it seems necessary (at least for me) to always have GPU acceleration off.

    https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform for bug reports

Maybe you are looking for