RICOH Web Enablement Solutions Suite: Summary of Updates 1.3 the Main Updates for Web Enablement Solutions Suite, Version 1.3, Are Summarized in the Table Below
Total Page：16
File Type：pdf, Size：1020Kb
Load more
Recommended publications
-
Unicode and Code Page Support
Natural for Mainframes Unicode and Code Page Support Version 4.2.6 for Mainframes October 2009 This document applies to Natural Version 4.2.6 for Mainframes and to all subsequent releases. Specifications contained herein are subject to change and these changes will be reported in subsequent release notes or new editions. Copyright © Software AG 1979-2009. All rights reserved. The name Software AG, webMethods and all Software AG product names are either trademarks or registered trademarks of Software AG and/or Software AG USA, Inc. Other company and product names mentioned herein may be trademarks of their respective owners. Table of Contents 1 Unicode and Code Page Support .................................................................................... 1 2 Introduction ..................................................................................................................... 3 About Code Pages and Unicode ................................................................................ 4 About Unicode and Code Page Support in Natural .................................................. 5 ICU on Mainframe Platforms ..................................................................................... 6 3 Unicode and Code Page Support in the Natural Programming Language .................... 7 Natural Data Format U for Unicode-Based Data ....................................................... 8 Statements .................................................................................................................. 9 Logical -
United States Patent (19) 11 Patent Number: 5,689,723 Lim Et Al
US005689723A United States Patent (19) 11 Patent Number: 5,689,723 Lim et al. 45) Date of Patent: Nov. 18, 1997 (54) METHOD FOR ALLOWINGSINGLE-BYTE 5,091,878 2/1992 Nagasawa et al. ..................... 364/419 CHARACTER SET AND DOUBLE-BYTE 5,257,351 10/1993 Leonard et al. ... ... 395/150 CHARACTER SET FONTS IN ADOUBLE 5,287,094 2/1994 Yi....................... ... 345/143 BYTE CHARACTER SET CODE PAGE 5,309,358 5/1994 Andrews et al. ... 364/419.01 5,317,509 5/1994 Caldwell ............................ 364/419.08 75 Inventors: Chan S. Lim, Potomac; Gregg A. OTHER PUBLICATIONS Salsi, Germantown, both of Md.; Isao Nozaki, Yamato, Japan Japanese PUPA number 1-261774, Oct. 18, 1989, pp. 1-2. Inside Macintosh, vol. VI, Apple Computer, Inc., Cupertino, (73) Assignee: International Business Machines CA, Second printing, Jun. 1991, pp. 15-4 through 15-39. Corp, Armonk, N.Y. Karew Acerson, WordPerfect: The Complete Reference, Eds., p. 177-179, 1988. 21) Appl. No.: 13,271 IBM Manual, "DOSBunsho (Language) Program II Opera 22 Filed: Feb. 3, 1993 tion Guide” (N:SH 18-2131-2) (Partial Translation of p. 79). 51 Int. Cl. ... G09G 1/00 Primary Examiner-Phu K. Nguyen 52) U.S. Cl. .................. 395/805; 395/798 Assistant Examiner-Cliff N. Vo (58) Field of Search ..................................... 395/144-151, Attorney, Agent, or Firm-Edward H. Duffield 395/792, 793, 798, 805, 774; 34.5/171, 127-130, 23-26, 143, 116, 192-195: 364/419 57 ABSTRACT The method of the invention allows both single-byte char 56) References Cited acter set (SBCS) and double-byte character set (DBCS) U.S. -
AIX Globalization
AIX Version 7.1 AIX globalization IBM Note Before using this information and the product it supports, read the information in “Notices” on page 233 . This edition applies to AIX Version 7.1 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2010, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document............................................................................................vii Highlighting.................................................................................................................................................vii Case-sensitivity in AIX................................................................................................................................vii ISO 9000.....................................................................................................................................................vii AIX globalization...................................................................................................1 What's new...................................................................................................................................................1 Separation of messages from programs..................................................................................................... 1 Conversion between code sets............................................................................................................. -
Data Encoding: All Characters for All Countries
PhUSE 2015 Paper DH03 Data Encoding: All Characters for All Countries Donna Dutton, SAS Institute Inc., Cary, NC, USA ABSTRACT The internal representation of data, formats, indexes, programs and catalogs collected for clinical studies is typically defined by the country(ies) in which the study is conducted. When data from multiple languages must be combined, the internal encoding must support all characters present, to prevent truncation and misinterpretation of characters. Migration to different operating systems with or without an encoding change make it impossible to use catalogs and existing data features such as indexes and constraints, unless the new operating system’s internal representation is adopted. UTF-8 encoding on the Linux OS is used by SAS® Drug Development and SAS® Clinical Trial Data Transparency Solutions to support these requirements. UTF-8 encoding correctly represents all characters found in all languages by using multiple bytes to represent some characters. This paper explains transcoding data into UTF-8 without data loss, writing programs which work correctly with MBCS data, and handling format catalogs and programs. INTRODUCTION The internal representation of data, formats, indexes, programs and catalogs collected for clinical studies is typically defined by the country or countries in which the study is conducted. The operating system on which the data was entered defines the internal data representation, such as Windows_64, HP_UX_64, Solaris_64, and Linux_X86_64.1 Although SAS Software can read SAS data sets copied from one operating system to another, it impossible to use existing data features such as indexes and constraints, or SAS catalogs without converting them to the new operating system’s data representation. -
JFP Reference Manual 5 : Standards, Environments, and Macros
JFP Reference Manual 5 : Standards, Environments, and Macros Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 817–0648–10 December 2002 Copyright 2002 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements. -
Iso/Iec Jtc 1/Sc 2/ Wg 2 N ___Ncits-L2-98
Unicode support in EBCDIC based systems ISO/IEC JTC 1/SC 2/ WG 2 N _______ NCITS-L2-98-257REV 1998-09-01 Title: EBCDIC-Friendly UCS Transformation Format -- UTF-8-EBCDIC Source: US, Unicode Consortium and V.S. UMAmaheswaran, IBM National Language Technical Centre, Toronto Status: For information and comment Distribution: WG2 and UTC Abstract: This paper defines the EBCDIC-Friendly Universal Multiple-Octet Coded Character Set (UCS) Transformation Format (TF) -- UTF-8-EBCDIC. This transform converts data encoded using UCS (as defined in ISO/IEC 10646 and the Unicode Standard defined by the Unicode Consortium) to and from an encoding form compatible with IBM's Extended Binary Coded Decimal Interchange Code (EBCDIC). This revised document incorporates the suggestions made by Unicode Technical Committee Meeting No. 77, on 31 July 98, and several editoiral changes. It is also being presented at the Internationalization and Unicode Conference no. 13, in San Jose, on 11 September 98. It has been accepted by the UTC as the basis for a Unicode Technical Report and is being distributed to SC 2/WG 2 for information and comments at this time. 13th International Unicode Conference 1 San Jose, CA, September 1998 Unicode support in EBCDIC based systems 1 Background UCS Transformation Format UTF-8 (defined in Amendment No. 2 to ISO/IEC 10646-1) is a transform for UCS data that preserves the subset of 128 ISO-646-IRV (ASCII) characters of UCS as single octets in the range X'00' to X'7F', with all the remaining UCS values converted to multiple-octet sequences containing only octets greater than X'7F'. -
AIX Globalization
AIX Version 7.2 AIX globalization IBM AIX Version 7.2 AIX globalization IBM Note Before using this information and the product it supports, read the information in “Notices” on page 227. This edition applies to AIX Version 7.2 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2015, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ......... v Interchange converters—8-bit ....... 97 Highlighting .............. v Interchange converters—compound text ... 100 Case-sensitivity in AIX ........... v Interchange converters—uucode ...... 102 ISO 9000................ v UCS-2 interchange converters ....... 103 UTF-8 interchange converters ....... 105 AIX globalization ........... 1 Miscellaneous converters ........ 107 Writing converters using the iconv interface ... 107 What's new in AIX globalization........ 1 Code sets and converters ........ 107 Separation of messages from programs ..... 1 Overview of iconv framework structures ... 108 Conversion between code sets ....... 1 Writing a code set converter ....... 110 Input method support .......... 2 Examples .............. 114 Converters overview........... 2 Input methods ............. 118 Using the message facility ......... 2 Input method introduction ........ 118 Setting multicultural support for devices .... 4 input method names .......... 119 Changing the language environment ..... 5 Input method areas ......... -
The Unicode Standard, Version 4.0--Online Edition
This PDF file is an excerpt from The Unicode Standard, Version 4.0, issued by the Unicode Consor- tium and published by Addison-Wesley. The material has been modified slightly for this online edi- tion, however the PDF files have not been modified to reflect the corrections found on the Updates and Errata page (http://www.unicode.org/errata/). For information on more recent versions of the standard, see http://www.unicode.org/standard/versions/enumeratedversions.html. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial capital letters. However, not all words in initial capital letters are trademark designations. The Unicode® Consortium is a registered trademark, and Unicode™ is a trademark of Unicode, Inc. The Unicode logo is a trademark of Unicode, Inc., and may be registered in some jurisdictions. The authors and publisher have taken care in preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The Unicode Character Database and other files are provided as-is by Unicode®, Inc. No claims are made as to fitness for any particular purpose. No warranties of any kind are expressed or implied. The recipient agrees to determine applicability of information provided. Dai Kan-Wa Jiten used as the source of reference Kanji codes was written by Tetsuji Morohashi and published by Taishukan Shoten. -
Peopletools 8.57: Global Technology
PeopleTools 8.57: Global Technology March 2020 PeopleTools 8.57: Global Technology Copyright © 1988, 2020, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. -
SAP-Migrationen Auf Unicode
SAP-Migrationen auf Unicode Sebastian Buhlinger SAP Consultant, HP-SAP EMEA CC © 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda 1. Introduction to Unicode 2. Unicode & SAP in General 3. Technology in Depth 3/31/2004 2 Introduction to Unicode 3/31/2004 3 1. Introduction to Unicode • History of character encoding • Problem of character encoding • From ACII to Unicode • What is Unicode exactly? • Unicode Encodings 3/31/2004 4 History of Character Encoding • Historically, computers were pretty slow, had fairly little memory and were very expensive • Up to 1960s I/O meant pushing holes into paper tapes • Most of the character sets date back to punch-card age and are designed with these cards in mind • In the early days of computers every hardware manufacturer used proprietary technology (and encodings) • International data interchange was no issue and so nothing needed to fit together 3/31/2004 5 Problem of character encoding • Which number is assigned to which character? • When typing an ‘A’ on the keyboard, the computer uses the character code as a basis for pulling the character shape of ‘A’ from a font file listing with the same binary number, and displays or prints it • The character ‘A’ may also have different integer values in different programs or data files (‘A’ might be ‘•’ in an Arabic font file) • In some instances no number available for certain characters (f.i. “ä” à Ä) • All data encoded in the form of binary numerical codes 3/31/2004 6 Character -
View Character Data Translation Guide
WWW.ASNA.COM Character Data Translation in DataGate/400 (Applies to Release 7.2 and above) One of the most important and overlooked features of ASNA DataGate is its ability to render character data (database fields and text) in various character encodings, as dictated by platforms and globalization requirements. Using the facilities of the iSeries and Windows, DataGate not only supports transparent iSeries-based EBCDIC character translation, but also the unique international character sets supported by particular platforms. This document discusses iSeries, Windows, and DataGate character translation functionality; past and present. By illuminating DataGate’s translation techniques and corresponding facilities, users are better equipped to configure and maintain robust character data applications. This document assumes some familiarity of applications programming with Windows, the iSeries, and DB2/400 database architecture. International Character Sets In the traditional green screen environment, developers were not as concerned with character translation issues, because in this hardware-based scheme, data entered into a green screen terminal was only rendered on a green screen terminal (or its report-printing twin). This “panacea” was disrupted by emerging globalization, the Internet, personal computers, and client/server-based access schemes. From very early on however, IBM and other computer vendors had introduced “national language” character sets reflecting local language and culture in international markets. In the case of IBM, these character sets were based on the original eight- bit EBCDIC character code. Later, to penetrate Asian and other markets with larger character sets, IBM introduced the idea of 16-bit character codes, known as Double- Byte Character Sets (DBCS). IBM identifies its various iSeries character encodings with Coded Character Set Identifiers (CCSIDs). -
UTF What? a Guide for Handling SAS Transcoding Errors with UTF-8 Encoded Data Michael Stackhouse, Lavanya Pogula, Covance, Inc
PharmaSUG 2018 - Paper BB-08 UTF What? A Guide for Handling SAS Transcoding Errors with UTF-8 Encoded Data Michael Stackhouse, Lavanya Pogula, Covance, Inc. ABSTRACT The acronyms SBCS, DBCS, or MBCS (i.e. single, double, and multi-byte character sets) mean nothing to most statistical programmers. Many do not concern themselves with the encoding of their data, but what happens when data encoding causes SAS to error? The errors produced by SAS and some common workarounds for the issue may not answer important questions about what the issue was or how it was handled. Though encoding issues can apply to any set of data, this presentation will be geared towards an SDTM submission. Additionally, a common origin of the transcoding error is UTF-8 encoded source data, whose use is rising in popularity by database providers, making it likely that this error will continue to appear with greater frequency. Therefore, the ultimate goal of this paper will be to provide guidance on how to obtain fully compliant SDTM data with the intent of submission to the FDA from source datasets provided natively in UTF-8 encoding. Among other topics, in this paper we first explore UTF-8 encoding, explaining what it is and why it is. Furthermore, we demonstrate how to identify the issues not explained by SAS, and recommend best practices dependent on the situation at hand. Lastly, we review some preventative checks that may be added into SAS code to identify downstream impacts early on. By the end of this paper, the audience should have a clear vision of how to proceed when their clinical database is using separate encoding from their native system.