BUG report: Distiller v.8.1.0 erroneously execute i/o-operations in PostScript programms

Distiller v.8.1.0 erroneously execute i/o-operations in PostScript programms (WinXP SP3 & Win2K3 RC1 SP2 platform).
Execution of the PS-code, contained file i/o operaions (see
i PLRM 3rd edition
, pp.73-87)
c %*************************** PS-File *********************************
c (c:\\temp\\File1.txt) (w) file closefile % Open file for write and close it
c %*********************************************************************
(or others file write ops.) produce invalidfileaccess error:
b =============== Distiller LOG =====================
> %%[ Error: invalidfileaccess; OffendingCommand: file ]%%
> Stack:
> (w)
> (c:\\temp\\file1.txt)
> %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
> %%[ Warning: PostScript error. No PDF file produced. ] %%
b ==================================================
Execution of the file read operations (file exist!)
c %*************************** PS-File *********************************
c (c:\\temp\\File2.txt) (r) file closefile % Open existing file for reading
c %*********************************************************************
or
c %*************************** PS-File *********************************
c (c:\\temp\\File2.ps) run % execute existing PS-program
c %*********************************************************************
produce undefinedfilename error:
b =============== Distiller LOG =====================
> %%[ Error: undefinedfilename; OffendingCommand: file ]%%
> Stack:
> (r)
> (c:\\temp\\file2.txt)
>
>
> %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
> %%[ Warning: PostScript error. No PDF file produced. ] %%
b ==================================================
b =============== Distiller LOG =====================
> %%[ Error: undefinedfilename; OffendingCommand: run ]%%
> Stack:
> (r)
> (c:\\temp\\file2.ps)
> %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
> %%[ Warning: PostScript error. No PDF file produced. ] %%
b ==================================================
It doesn't matter, in what folder operation is carried out system %TEMP% or User %TEMP% (not in %HOMEPATCH%!) file i/o
b don't work.
With mentioned [in KB http://www.adobe.com/devnet/acrobat/downloads/Acrobat_SDK_readme.html ] command line switch «-F» all works correctly.
This "feature" of the Acro8 (and Acro9? see http://www.adobeforums.com/webx/.59b69fa1 ) does impossible execution of the PostScript programs of variable data print.
What to do that Distiller the beginnings it is correct to work (file i/o into %TEMP%-folders) without «F»-switch?

I don't use Acrobat SDK, i make PostScript-programs for the var.data print, f.e. labels with wire name, numbers, barcode etc.; Distiller plays role RIP, carrying out the program.
As a data source at execution of these programs files of various formats can be used: ANSI/UNICODE text, binary (f.e. PhotoShop-RAW data), PostScript (f.e. «print-in-file» from Illustrator) file and others. The same programs can write what or given on a disk (tmp-files), for example the pointer to the data in a source file or the debug information.
For me has surprised that in 8 Acrobat'е all it has suddenly ceased to work, though in early versions and ghostScript all is fulfilled correctly. I have assumed that obviously developers had been limited possibility of data write/reading a disk and, most likely by a TEMP-folder. However even in the TEMP-folders setted by means of a variable %TEMP% of write operation at execute of PostScript-program by Distiller it was not possible to make. Also attempt to read/execute a file which is in a TEMP-folder was unsuccessfully completed also.
During search in the Internet I have found article specified above ( http://www.adobe.com/devnet/acrobat/downloads/Acrobat_SDK_readme.html ) in which it is underlined possibility by default operations of file I/O in a TEMP-folder, however impossibility it to make contrary specified in this article, have forced me to write to this forum so it is read by Acrobat developers.

Similar Messages

  • Bug report for erroneous Vimeo password error

    If your Vimeo password contains a left parenthesis '(', when you attempt to share to Vimeo from Final Cut Pro X, it will tell you that your Vimeo password is invalid. If you change your password to remove the parenthesis, sharing will then be successful. I repro'd this issue with two different passwords containing parentheses.

    FYI, Apple doesn't read these forums for bug reports. You need to use the "Send Feedback" option in the Final Cut Pro X menu to make sure they see this.

  • Bug report, Beta 2.12 Standard Edition

    Bug report: redundant, confusing, and apparently erroneous calls to
    jdoPreClear
    and jdoPostLoad. Note in output the null name in the third iteration.
    Hi,
    A lot of information being sent. Sorry, but I think you'll find it
    helpful. I expected the exact same sequence of calls to jdoPreClear
    and jdoPostLoad on the 2nd and third iteration. In fact, since,
    retain values is true, and no changes are being made, I expected that
    jdoPreClear and jdoPostLoad would not be called at all on the 2nd and
    3rd iteration.
    David Ezzio
    Using 2.12 Beta, standard edition
    Business method uses one PM. Configured to datastore transaction,
    retainValues == true, non-TR == false, and non-TW == false.
    The business methods open a transaction and leave it open.
    The client calls commitTransaction() to close the open
    transaction.
    Two persistent objects, Widget and Box. Each implement
    InstanceCallbacks and put out a message in jdoPreClear ("will be
    made hollow") and in jdoPostLoad ("has been made persistent-clean").
    The Widget has a reference to its Box. The number in parenthesis
    is the sequence number obtained from the object ID.
    Business methods implementation:
    public ArrayList getWidgetsByName(String name)
    Transaction trans = pm.currentTransaction();
    if (!trans.isActive())
    trans.begin();
    Collection c = (Collection) widgetsByOneName.execute(name);
    ArrayList aList = new ArrayList(c);
    widgetsByOneName.close(c);
    return aList;
    public void commitTransaction()
    Transaction trans = pm.currentTransaction();
    if (trans.isActive())
    trans.commit();
    Output: from three loops that:
    call findWidgetsByName("Maxi-Widget")
    list the widgets returned
    call commitTransaction()
    finding Maxi-Widgets ...
    Widget Maxi-Widget (650) has been made persistent-clean
    Box Large (652) has been made persistent-clean
    Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
    Widget Maxi-Widget (709) has been made persistent-clean
    Box Large (710) has been made persistent-clean
    Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
    Widget Maxi-Widget (708) has been made persistent-clean
    Box Large (713) has been made persistent-clean
    Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
    Widget Maxi-Widget (700) has been made persistent-clean
    Box Large (717) has been made persistent-clean
    Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
    Widget Maxi-Widget (707) has been made persistent-clean
    Box Large (716) has been made persistent-clean
    Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
    Finding them again
    finding Maxi-Widgets ...
    Widget Maxi-Widget (650) will be made hollow
    Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
    Widget Maxi-Widget (709) will be made hollow
    Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
    Widget Maxi-Widget (708) will be made hollow
    Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
    Widget Maxi-Widget (700) will be made hollow
    Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
    Widget Maxi-Widget (707) will be made hollow
    Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
    Finding them yet again
    finding Maxi-Widgets ...
    Widget null (650) will be made hollow
    Widget Maxi-Widget (650) has been made persistent-clean
    Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
    Widget null (709) will be made hollow
    Widget Maxi-Widget (709) has been made persistent-clean
    Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
    Widget null (708) will be made hollow
    Widget Maxi-Widget (708) has been made persistent-clean
    Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
    Widget null (700) will be made hollow
    Widget Maxi-Widget (700) has been made persistent-clean
    Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
    Widget null (707) will be made hollow
    Widget Maxi-Widget (707) has been made persistent-clean
    Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
    -- All done!

    Due to better understanding on my part, and the fixes in Beta 2.2, the
    issues raised in this thread are put to rest.
    Abe White wrote:
    >
    We'll investigate further. Stay tuned...
    "David Ezzio" <[email protected]> wrote in message
    news:[email protected]..
    Abe,
    Actually, it doesn't make sense. The first iteration shows
    jdoPostLoad is called just prior to using the fields of Widget and Box.
    After the commit, the instances are not cleared. So far, so good.
    In the second iteration, we see that jdoPreClear is called, but
    jdoPostLoad is not called. Yet the values are there for use during the
    call to Widget.toString() and Box.toString() within the iteration. How
    did that happen?
    On the third iteration, now the value of name is null, but last we
    looked it was available in the second iteration. Other than that, I
    agree that the third iteration looks ok, since it is being cleared and
    loaded prior to use. But in the jdoPreClear, the values should be there
    since the values were used in the previous iteration and are not cleared
    at transaction commit due to retainValues == true.
    David
    Abe White wrote:
    David --
    I believe the behavior you are seeing to be correct. Section 5.6.1 of
    the
    JDO spec outlines the behavior of persistent-nontransactional instancesused
    with data store transactions. As you can see, persistentnon-transactional
    instances are cleared when they enter a transaction; thus the calls to
    jdoPreClear. When the default fetch group is loaded again (like whenyou
    access the name of the widget) a call to jdoPostLoad is made.
    You are seeing the name of one instance as 'null' in the third iterationof
    your loop because the instance has been cleared in the second iteration,and
    the jdoPreClear method is not modified by the enhancer (see section10.3).
    Make sense?

  • Bug report follow-up

    is there a way to follow-up on a bug report that i submitted?  i have the bug number, but would like to see if the report was understood, filled out properly and determine the status of the bug report.
    thanks,
    doug

    They comment on bugs if actions were taken. Otherwise - don't expect any feedback.

  • Solaris8 and 9 (possibly 7) /dev/poll driver bug report.

    Hello,
    I'd like to report a bug in the solaris 8 and 9 /dev/poll driver (poll(7d)).
    As i do not have a support account with sun or anything like that, there
    seems to be no other way to do that here (which is of course a very sad
    thing).
    Bug details:
    The /dev/poll device provides an ioctl-request (DP_ISPOLLED) for checking
    if a particular filedescriptor is currently in the set of monitored
    filedescriptors for that particular /dev/poll fd set (open /dev/poll fd).
    A quote from the documentation of the poll(7d) manual page taken from
    Solaris9:
    "DP_ISPOLLED ioctl allows you to query if a file descriptor is already in
    the monitored set represented by fd. The fd field of the pollfd structure
    indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1
    if the file descriptor is in the set. The events field contains the
    currently polled events. The revents field contains 0. The ioctl returns 0
    if the file descriptor is not in the set. The pollfd structure pointed by
    pfd is not modified. The ioctl returns a -1 if the call fails."
    It says that when you query for an filedescriptor which is currently being
    monitored in the set, that it would return 1, and change the events field of
    the pollfd structure to the events it's currently monitoring that fd for.
    The revents field would be set to zero.
    However the only thing which actually happens here, is that FD_ISPOLLED
    returns 1 when the fd is in the set and 0 if not. When the fd is in the
    set, when FD_ISPOLLED returns 1, the events field remains unmodified, but
    the revents field gets changed.
    A small sample code to illustrate:
    #include <stdio.h>
    #include <unistd.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <sys/devpoll.h>
    main() {
    struct pollfd a;
    int dp_fd = open("/dev/poll", O_WRONLY);
    a.fd = 0; /* stdin */
    a.events = POLLIN; /* we monitor for readability, POLLIN=1 */
    a.revents = 0;
    write(dp_fd, &a, sizeof(a));
    a.fd = 0;
    a.events = 34; /* filled in with bogus number to show malfunctioning */
    a.revents = 0;
    printf("DP_ISPOLLED returns: %d\n", ioctl(dp_fd, DP_ISPOLLED, &a));
    printf("a.fd=%d, a.events=%hd, a.revents=%hd\n", a.fd, a.events,
    a.revents);
    According to the documentation of /dev/poll and namely DP_ISPOLLED this
    program is supposed to print the following:
    DP_ISPOLLED returns: 1
    a.fd=0, a.events=1, a.revents=0
    However it prints the following:
    DP_ISPOLLED returns: 1
    a.fd=0, a.events=34, a.revents=1
    You can take any number instead of '34' and it will simply remain untouched
    after the DP_ISPOLLED ioctl-request.
    I hope it's clear now that the solaris8 and solaris9 (and probably solaris7
    with /dev/poll patch too) DP_ISPOLLED implementation is broken.
    This bug is also easily illustrated by looking at the solaris8 kernel sourcecode:
    <snippet osnet_volume/usr/src/uts/common/io/devpoll.c:dpioctl()>
    case DP_ISPOLLED:
    pollfd_t pollfd;
    polldat_t *pdp;
    if (pollfd.fd < 0) {
    mutex_exit(&pcp->pc_lock);
    break;
    pdp = pcache_lookup_fd(pcp, pollfd.fd);
    if ((pdp != NULL) && (pdp->pd_fd == pollfd.fd) &&
    (pdp->pd_fp != NULL)) {
    pollfd.revents = pdp->pd_events;
    if (copyout(&pollfd, (caddr_t)arg,
    sizeof(pollfd_t))) {
    mutex_exit(&pcp->pc_lock);
    DP_REFRELE(dpep);
    return (set_errno(EFAULT));
    *rvalp = 1;
    </snippet>
    its' clearly visible that the code writes the current monitored events to
    the revents field:
    'pollfd.revents = pdp->pd_events;'
    and that it doesnt set revents to zero.
    It's funny to see that this has been like this since Solaris8 (possibly 7). That means nobody ever used DP_ISPOLLED that way or people were simply to lazy to file a bug report.
    Another funny thing related to this. is that Hewlett-Packard did seem to know about this. Since HP-UX11i version 1.6 they also support /dev/poll. From their manual page i ll quote some sentences from their WARNING session:
    "The ioctl(DP_ISPOLLED) system call also returns its result in the revents member of the pollfd structure, in order to be compatible with the implementation of the /dev/poll driver by some other vendors."
    Hopefully this will get fixed.
    I also like to reexpress my very negative feelings towards the fact that you're not able to file bug reports when you do not have a support contract. Ridiculous.
    Thanks,
    bighawk

    Have I mentioned how much i love my playbook now Great job on os 2.0

  • Did you know that Google toolbar doesn't work properly in FF rc1? I have filed a bug report to Google about this

    The Google toolbar doesn't recognize a left mouse click when selecting a 'suggestion'. It's OK using the keyboard, however. I have filed a bug report with Google, but as this is an important extension thought you should know.

    See also:  http://forums.adobe.com/message/4662367#4662367
    -Noel

  • Bug Report: The keyboard focus doesn't automatical...

    Bug Report: When a conversation window opens, the focus doesn't automatically land in the chat entry text field.
    Since the new interface for Skype was introduced officially in Skype 7.0, there is a bug with the system/keyboard focus for a new conversation window. When Skype is in "Split Window View" and each new conversation automatically pops up in a separate window, the system/keyboard focus doesn't land in the chat entry edit field. Instead, the user has to press Shift+TAB a couple of times, to move it there and reply to the chat message received. This especially problematic for screen reader users, who rely on keyboard navigation. This mainly occurs when a new conversation is started with an incoming message, but it sometimes occurs when moving the focus out of that conversation window and later back in it again (while it is still opened).
    Steps to reproduce it:
    1. From "View" menu, activate the "Split Window View", if it is not already enabled.
    2. From Tools -> Options -> IM & SMS -> IM settings, enable "Open a new window when I receive a new message in Split Window View", if it is not already enabled.
    3. From Tools -> Options -> Advanced, activate "Enable accessible mode", if it is not already enabled.
    4. Activate the "Save" button, to save the changes.
    5. Close all windows, related to Skype. You may keep only the main window opened.
    6. Tell someone to send you a chat message. When the message arrives, Move the system focus to the conversation window in question, preferably with Alt+TAB. The system/keyboard will not land in the chat entry edit field as it did in Skype 6.21 and earlier and as it should by default, but in some unknown place in the window.
    7. Move the system/keyboard focus in the chat entry edit field and keep it there.
    8. Switch to another window, preferably from another application.
    9. With Alt+TAB, switch back to the window of the opened Skype conversation. There is a chance that the system/keyboard focus will not land in the chat entry edit field as it did in Skype 6.21 and earlier and as it should do by default, but again in some unknown place in the conversation window. But that is harder to reproduce.
    Test environment:
    - Operating system: Windows 8.1 Pro N, 64-bit, in Bulgarian with all locale settings set to "Bulgarian".
    - Skype version: 7.0.0.102 for Desktop.

    This is a known problem, but Skype have not given us an estimated time for a fix.
    Traditionally, Skype updates have been roughly monthly, so we are due a new version sometime soon. Many of us here are hoping that is has a bunch of fixes for the UI, the focus problem being one of them.
    Sean Ellis - uses Skype chat for serious work
    Click here to read my blog post on Skype 7 and basic principles of GUI design

  • Bug report: Naming a Bin after creating it with drag'n'drop

    There seems to be a small bug when giving a newly created bin a name after creating it by drag'n'drop of several clips onto the "New Bin" icon. 
    To reproduce:
    Select some clips in your project browser
    Drag them onto the New Bin button
    A new bin is created with the clips in it
    - the bin name for it appears to be selected, and editable - just as if you had created a new empty bin by clicking the New Bin button
    - type in a new name - it accepts the name fine, now press enter.
    - your new name disappears, and *now* you are really in the mode to edit the bin name
    - type your name again, and it works.
    Work around:
    When creating new bins by using drag'n'drop of clips onto the New Bin button, first press enter once to enter into the proper edit mode before giving the bin a new name.
    (is there a better place to file bug reports?)
    Version 6.0.1 (014 (MC: 264587))
    Hardware Overview:
      Model Name:          Mac Pro
      Model Identifier:          MacPro5,1
      Processor Name:          Quad-Core Intel Xeon
      Processor Speed:          2.8 GHz
      Number Of Processors:          1
      Total Number Of Cores:          4
      L2 Cache (per core):          256 KB
      L3 Cache:          8 MB
      Memory:          8 GB
      Processor Interconnect Speed:          4.8 GT/s
      Boot ROM Version:          MP51.007F.B03
      SMC Version (system):          1.39f11
      SMC Version (processor tray):          1.39f11
    OS X 10.6.8

    Er, just answered my question about bug reports by reading the "read this before posting" link above
    But I'll leave this here for the work-around in case anyone else needs it.

  • Bug report: 3.2; DAC; GridControl; Navigation - Invalid reaction to mouse drag

    Hi,
    This is a bug report, I think.
    I have a one-column GridControl with mandatory column. Normally, DAC framework prohibits from navigation out of empty field and emits one of those DAC-1002 or DAC-603 errors. The only exception I noticed was a double-click on another row. In this case navigation allowed but an error is still produced.
    Today I was playing with this GridControl and discovered that I can drag the yellow frame across rows. And here comes a bug - GridControl doesn't change the current row on InfoBus according to current selection marked by yellow frame.
    In my case it brings the following problem: if the cursor is placed on the new empty row, user drags the cursor to another row and then tries to use any other navigation means except dragging, he gets a navigation error. DAC framework still thinks that the current row is the empty one and produces an error telling that the attribute cannot be empty.
    Dev Team, any comments?
    Regards,
    Vladimir

    Hmm... Nobody answers. I'll try another variation of the same question.
    DAC framework implicitly validates attributes on the base of Mandatory constraint in the Entity Object definition. Is it possible to set the level of this validation? For example, I want to conduct validation only when user navigates out of the row or the whole rowset, but not when he just leaves a field.
    Regards,
    Vladimir

  • Bug report: vpn (ipsec) interface number in snmp always change

    Hi,
    this is a bug report for RV082 hardware version 3 and 4, firmware version 1.x, 2.x and 4.x (all latest versions). I hope someone from cisco/belkin reads it.
    Summary:
    The snmp interface number of a VPN Tunnel change when the VPN tunnel disconnect and then re-connects.
    What should happend:
    The VPN Tunnel number 1, should always have the same snmp interface number. In RV082 v4, this number should always be 10. For example, the LAN, WAN1 and WAN2 always have the same snmp interface number.
    What is the problem:
    The VPN Tunnel number 1 change the snmp interface number, from 10, to 11, to 12, etc.
    How to reproduce:
    create a VPN Tunnel using 2 RV082 or 1 RV082 and 1 RV042. Once the VPN Tunnel is connected write down the snmp interface number. A few days later, disconnect the cable of block internet access. Then restore the internet conection and write down the snmp interface number, you should note that the snmp interface number have changed.
    Tools used:
    PRTG Network Monitor
    Please take a look at the attached image, note all the "ppp" interfaces, theres only 1 VPN Tunnel (gateway-to-gateway) defined.

    Hi Tom,
    many thanks for your reply.
    I see that I have to call Tech-support, in order to report a very technical situation, explaining them this is a bug report and I want them to make a better product.
    Since I won't pay a dime for this problem to be fixed, I can only see pain in this path(calling to speak with a tech support representative).
    I also readed that Belkin has bought Linksys, so I don't know if the RV082 will remain with Cisco or will go with Belkin.
    So, my only hope is to document this bug, that is pressent inall firmware version and hardware version of the RV082 as of today.
    many thanks for your help,
    regards,
    Oliver

  • Bug Report: Shortcuts for Adjustments in 3.1

    I have verified that bug with a brand new test account (Aperture 3.1 and OS 10.6.4 with latest Pro Update):
    - Make an adjustment to an NEF-file
    - save that adjustment as a preset
    - assign a keyboard shortcut to that specific adjustment
    Switch to the next NEF-file and make your usual adjustments:
    - initiate that shortcut to apply the already saved preset/adjustment
    All of a sudden, all already applied adjustments are set back to defaults!!!!
    To sum up:
    Shortcuts are presently not useable!
    Bug Report was filed!
    Any observations???

    I got it myself. My shortcut combination contained the option key. That causes AP to replace any adjustments already made to the image. You have to use a keyboard short cut combination without the option key.
    The question is, why AP 3.1 is not smart enough to refuse such a combination??? In version 3.0.x everything worked fine!!!

  • [Bug Report] Rhythmbox missing depedency for "tdb"

    Here's the bug report:
    https://bugs.archlinux.org/task/29310
    Just tryed to install Rhythmbox and had to track down that depedency.  Just figured I'd post it here to try to give it some more attention.  Seems like a pretty easy fix that could save some users some frustration.  Go give it a vote on the bug report so the developers will see this.

    For Oracle TopLink customers can report bugs using a support request on metalink.oracle.com.
    For TopLink Essentials customer can directly file bugs in the GlassFish system.
    Doug

  • Bug Report: Feature Request/Bug Report Form

    Re: Feature Request/Bug Report Form
    https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
    The Feature Request/Bug Report Form does not include a drop-down option for Creative Cloud.

    Hi Stephen,
    We are collecting feature requests as idea threads here on the forums versus using that form. If you believe you have discovered a bug with Creative Cloud please post about it here on the forums.
    Thanks,
    -Dave

  • Bug report submitted re Input Mode affected by ACR 4.2 Mac - very annoying

    Just submitted a bug report to Adobe. ACR 4.2, Photoshop 10, Tiger 10.4.10, PowerPC.
    Most users in the US and the UK may not even run across this situation.
    If you use a non US standard keyboard layout as your Input mode, causing ACR 4.2 to launch, either from Bridge, Photoshop, or the Finder, this switches the selected keyboard to the US standard. If you click the Cancel button in ACR, the keyboard reverts back to your custom keyboard layout; but if you click Open, the US standard keyboard remains set even after quitting Photoshop, ACR and Bridge.
    It took me a while to figure out what was causing me to loose my preferred keyboard layout. It didn't dawn on me ACR 4.2 was doing it. Observing a few screen shots led me to discover the cause.
    It's most annoying.

    The choices in Bridge > Preferences > Advanced > International > Keyboard are limited, and they do not allow for choosing custom keyboard layouts.
    I need the custom keyboard layouts for a variety of reasons, such as being able to type in seven languages with my most used one without switching, two Russian layouts to allow for two non-standard ways of encoding Russian fonts, etc.

  • Bug report: A keyboard layout is incorrect on the remote with Japanese keyboard

    This is a bug report for Microst Remote Desktop
    ===================================================
    ## Summary
    A keyboard layout is incorrect on the remote with Japanese keyboard
    ## Version Information, I tested
    * Client
        * Case 1
            * MacBook Pro with JIS106 Keyboard
            * Mac OS X Lion 10.7.5
            * Microsoft Remote Desktop 8.0.24308
        * Case 2
            * MacBook Pro with JIS106 Keyboard
            * Mac OS X Mavericks 10.9.1
            * Microsoft Remote Desktop 8.0.24308
    * Remote
        * Case 1
            * Windows 7 Professional Japanese
        * Case 2
            * Windows Server 2008R2 Datacenter Japanese
        * Case 3
            * Windows Server 2012R2 Datacenter Japanese
    ## Detail of bug
    When login from Mac OS X with Microsoft Remote Desktop, the keyboard layout is always incorrect on the remote.
    The client machine have a built-in keyboard of JIS 106 layout,
    and the primary language is set to Japanese.
    But on the remote, the keyboard layout is US 101.
    So a input of Shift+2 does not result " but @.
    I've seen the above behavior on the 3 remote enviornments described the above.
    This bug did not occcur with Microsoft Remote Desktop Connection Client for Mac 2.1.1, even if the system language is English and keyboard layout is Japanese.
    ## Captures
    I've took some of screen captures.
    I'm sorry for the capture includes Japanese words, so I added description in English.
    Capture 1:
    Mac OS X Keyboard Setting
    Capture 2:
    Windows Server 2012R2 Screen Keyboard
    Capture 3:
    Windows Server 2012R2 Screen Keyboard, with a additional registry key configured.

    This bug also affects the Canadian English settings.  If the client is set to Canadian English with a US keyboard the remote server is setup using a Canadian French keyboard.  Using the language selection in the toolbar you can temporarily correct
    the problem but the keyboard resets to french at the most inopportune times.  The was a problem in the earlier RDP client and was fixed so it's sad to see it reoccur in the new client.
    Lawrence

Maybe you are looking for