ABSTRACT Agent-Oriented Modelling and Simulation of a Ceramic Factory
Agent-Oriented Modelling and Simulation of a Ceramic Factory
Kuldar Taveter
VTT Information Technology (Technical Research Centre of Finland),
P.O.Box 1201, FIN-02044 VTT, Finland
Kuldar.Taveter@vtt.fi
Tallinn Technical University, Department of Informatics,
Raja 15, 12618 Tallinn, Estonia
Reet H??l
Tallinna Keraamikatehas AS,
Maleva 2, Tallinn 11711, Estonia,
reet@keraamikatehas.ee
KEY WORDS agent, enterprise modelling, manufacturing rule, manufacturing process ABSTRACT
We propose a modelling approach for creating simulation environments. The modelling process consists of the phases of analysis and design. The analysis is accomplished by extended use cases. In the design, the steps of extended use cases are first transformed to commitment-based models of interactions between the agents and after that to models of activities and reaction rules, defining the behaviours of agents. The approach is evaluated by using the case study of a real ceramic factory located in Tallinn, Estonia. The models created serve as a foundation for implementing the actual simulation environment the development of which is under way.
1 INTRODUCTION
Agent-orientation is emerging as a new paradigm in software and information systems engineering that emphasizes the fundamental role of autonomous actors/agents and their mental state, and of communication and interaction, for analyzing and designing organizations and organizational information systems. The modelling paradigm of agent-orientation is useful for creating both information systems and simulation environments for different problem domains. It enables to use the same terms like beliefs, perceptions, memory, goals, commitments, etc. for humans, institutions, and artificial (e.g., software-controlled) systems. According to this paradigm, communication between different artificial (software-controlled) systems and between systems, institutions, and humans is understood as communication between agents.
We propose an agent-oriented modelling approach that is suitable for developing simulation environments. We have used the approach proposed for modelling the problem domain and business/manufacturing processes of a ceramic factory located in Tallinn, Estonia. The resulting models can be quite straightforwardly turned into the implementation constructs of the actual simulation environment the development of which is under way.
2 ANALYSIS BY EXTENDED USE CASES
For the step of analyzing the problem domain at hand, we utilize use cases with goals proposed in /1, 2/. In Table 1, the use case “Process production order”, describing the processing of a production order by the Production Department of the ceramic factory, is presented. The goal of the use case is given in an informal way. It is semi-formalized later on in the phase of design. The use case is modelled from the perspective of the Sales Department (scope) with the Production Department in focus which means that the goal of the use case is the so-called user goal, the goal of the actor trying to get work (primary task) done. The use case is triggered by the receiving of the production order by the Production Department from the Sales Department which is therefore called the primary actor of the use case. Resource Units are termed secondary actors because they are the ones from which the actor in focus needs assistance to satisfy its goal. The scenario represented in Table 1 includes the main steps needed for satisfying the goal. Because of the lack of space, the extensions of the main success scenario have been omitted.
Table 1. Extended use case for the business/manufacturing process “Process production order”
USE CASE 1 Process production order
Goal in Context Sales Department issues a request to produce a product set and expects the product set to be produced
Scope & Level Sales Department, Primary Task
Preconditions Customer has issued a production order to the Sales Department
Success End
Condition
The product set has been produced
Failed End
Condition
The product set has not been produced
Primary Actor Secondary Actors The Sales Department Resource Units
Trigger A production order comes in
DESCRIPTION Step Action
1 A production order is received from the Sales Department
2 A production plan for the production order is instantiated
3 Each production activity of the production order is requested to be scheduled by
the respective Resource Unit, and the scheduling of the production activity is
registered
4 The scheduled production order is sent to the Sales Department
5 The acceptance of the scheduled production order is received from the Sales
Department
6 All Resource Units are requested to perform the production activities scheduled
7 Upon receiving a message about a capacity conflict from a Resource Unit, the
production activities affected are requested to be rescheduled by the Resource
Unit, and the rescheduling of each production activity is registered
8 Upon receiving a message about the start of a production activity from the
corresponding Resource Unit, the start of the production activity is registered
9 Upon receiving a message about the completion of a production activity from the
corresponding Resource Unit, the completion of the production activity is
registered
10 If a time conflict is detected, the production activities affected are requested to be
shifted right by the corresponding Resource Units, and the shift of each
production activity is registered
11 Sales Department is informed about the completion of the production order
3 DESIGN BY AOR MODELLING
3.1 Principles of Agent-Object-Relationship (AOR) Modelling
Agent-Object-Relationship diagrams were proposed in /3, 4/ as an agent-oriented extension of Entity-Relationship-diagrams, or UML-style class diagrams. In order to capture more semantics of the dynamic and deontic aspects of organizations involved in business and manufacturing processes and their information systems, such as the events and actions related to the ongoing business and manufacturing processes, it is proposed to make an ontological distinction between active and passive entities, that is, between agents and ordinary objects. AOR modelling suggests that the semantics of business/manufacturing transactions can be more adequately captured if the specific business/manufacturing agents associated with the involved events and actions are explicitly represented in organizational as well as in inter-organizational information systems in addition to passive business/manufacturing objects.
3.1.1 Domain Modelling
In AOR modelling, an entity is either an agent, an event, an action, a claim, a commitment, or an ordinary object. An organization is viewed as a complex institutional agent, being involved in a number of interactions with external agents and consisting of a number of internal agents that perceive events and perform actions on behalf of it. Internal agents may be humans, artificial agents (such as software agents, agentified information systems, robots, or agentified embedded systems), or institutional agents (such as organization units).
As usual, entity types are visually represented by rectangles while relationship types are represented by connection lines (possibly with crows feet endings in order to indicate multiplicity). While an object type is visualized as an ordinary rectangle, an agent type is graphically rendered as a rectangle with rounded corners. An internal agent type is visualized by such a rectangle with a dashed line drawn within the institutional agent rectangle it belongs to (like ResourceUnit in Figure 1). An instance of an agent type is distinguished from an agent type by underlining its name (like the Production Department in Figure 1).
Figure 1. The agent diagram of the domain of a ceramic factory.
The domain model of the ceramic factory depicted in Figure 1 is based on the principles of creating an ontology for constructing scheduling systems presented in /15/. In Figure 1, the institutional agent Ceramic Factory includes the (institutional) internal agents Sales Department, Production Department, and Factory Management, and (instances of) the (institutional) internal agent type Resource Unit. Among the others, the latter has subclasses Mouldmaking Unit and Store, of both of which there is just one instance (hence both of the names are underlined). In addition, there is an external agent type Customer. The agents have knowledge/information about their proprietary objects and about objects that are shared between agents of different types. For example, each agent of the type Resource Unit has knowledge about
its proprietary objects of the type Resource which is divided into the subtypes ReusableResource, like a set of ceramic moulds, and DiscreteStateResource, like a worker or a machine or a combination of these. Each DiscreteStateResource consists of the internal object Capacity, which specifies the number of resources and batch size, and (instances of) the internal object type CapacityInterval. For each CapacityInterval, the start and end times of the interval are specified. Each
CapacityInterval can be attached to one or more instances of the object type ProductionActivity. The allocation of capacity intervals of a DiscreteStateResource to production activities is different for instances of the two subclasses of
DiscreteStateResource: UnitCapacityResource and BatchCapacityResource. An instance of UnitCapacityResource, like a worker, can process only one product at a time, whereas a BatchCapacityResource, like a kiln, can process simultaneously up to batchSize products. This is also reflected by the respective two subclasses of CapacityInterval: UnitCapacityInterval and BatchCapacityInterval.
An entity of the class ProductionActivity can have the status isUnscheduled, isScheduled, isInProcess, or isCompleted. It also has the intensional predicates hasSchedulableInterval, hasCapacityConflict, hasTimeConflict, and mustBeRescheduled which are accessed by the agents’ activities. An entity of another shared object type ProductionOrder satisfies one of the following status predicates: isPreliminary, isScheduled, isProposed, isAccepted, isRejected, isCompleted, or isDelivered. Also entities of the object type Product of the Production Department and of the shared object type Invoice have status predicates. There are associations of the type PrecedenceInterval between instances of ProductionActivityType. Each association specifies the lower bound and upper bound of the temporal separation between production activities of two types.
3.1.2 Actions and events
In a business or manufacturing domain, there are various types of actions performed by agents, and there are various types of state changes, including the progression of time, that occur in the environment of the agents. For an external observer, both actions and environmental state changes constitute events. In the internal perspective of an agent that acts in a business or manufacturing domain, only the actions of other agents count as events.
Actions create events, but not all events are created by actions. Those events that are created by actions, such as delivering a product to a customer, are called action events. Examples of business/manufacturing events that are not created by actions are the fall of the demand for a particular product below a certain threshold, or missing the deadline of paying an invoice.
Actions make up activities. While an action happens at a time point (i.e., it is immediate), an activity is being performed during a time interval (i.e., it has duration), and consists of a set of actions, performed by a particular agent.
We make a distinction between communicative and non-communicative actions and events. Many typical business/manufacturing events, such as receiving a production order or a sales quotation, are communication events. The expressions receiving a message and sending a message may be considered to be synonyms of perceiving a communication event and performing a communication act.
Business/manufacturing communication may be viewed as asynchronous point-to-point message passing. As opposed to the low-level (and rather technical) concept of messages in object-oriented programming, AOR modelling assumes the high-level semantics of speech-act-based Agent Communication Language (ACL) messages (see /5, 6/).
3.1.3 Commitments and claims
Commitments are fundamental components of business/manufacturing interaction processes. They are defined in /14/ as ternary relationships between two agents and a ‘context group’ they both belong to. Representing and processing commitments and claims in information systems explicitly helps to achieve coherent behaviour in interaction processes.
Commitments to perform actions (to-do commitments) which we are interested in typically arise from certain communication acts. For instance, sending a sales quotation to a customer commits the vendor to reserve adequate stocks of the quoted item for some time. Likewise, acknowledging a production order implies the creation of a commitment to produce the ordered products on or before the specified delivery date.
In the perspective of a particular agent, commitments of other agents are viewed as claims against them.
3.2 Modelling Business/Manufacturing Processes by Interaction Frames.
In an external AOR model, we adopt the view of an external observer who is observing the (prototypical) agents and their interactions in the problem domain under consideration. Typically, an external AOR model will have a focus, that is an agent, or a group of agents, for which we would like to develop an interaction model.
In the view of an external observer, all actions of agents are at the same time also events, and commitments are also claims, exactly like two sides of the same coin. Therefore, an external AOR model contains, besides the agent and object types of interest, the action event types and commitment/claim types that are needed to describe the interaction between the focus agent(s) and the other types of agents. An interaction frame diagram, in an external AOR model, provides a static picture of the possible interactions and evolvement of commitments/claims within them. The interaction frame diagram, covering the ceramic factory’s internal business/manufacturing process type of processing a production order, is depicted in Figure 2.
Figure 2. The interaction frame for the business/manufacturing process type of processing a production order with three focus agents.
In the graphical notation of AOR modelling, commitments are coupled with the action events satisfying them. For example, in Figure 2 the commitment of the produceProduct type is coupled with the action event of the corresponding type.
The interaction frame in Figure 2 corresponds to the use case represented in Table 1. Its first message type is the request of the Sales Department to the Production Department to process the given production order. The next message types between the same agents deal with proposing and accepting a schedule for the production order. After that, the commitment of the type produceProduct of the Production Department towards the Sales Department is formed and met. The occurrence of an action event of the type performProductionActivity between a Resource Unit and the Production
Department is preceded by the formation of a commitment/claim of the corresponding type, as a consequence of the exchange of communicative action events of the types request schedule ProductionActivity, and inform (production-activity-
scheduled). The messages of the types inform (production-activity-in-process) and inform (production-activity-completed) inform the Production Department about the status changes of production activities. The rest of the communicative action event types between the Production Department and a Resource Unit deal with reactions to possible capacity and time conflicts in the schedule as described in /16/. Finally, messages of the types inform(product-produced) and inform(product-delivered) between the agents ProductionDepartment and Sales Department and Store and Sales Department inform the latter about the producing and delivery of the product, respectively.
3.3 Modelling Agent Behaviours by Activity Diagrams
Our modelling notation is based on the semantic framework of Knowledge-Perception-Memory-Commitment (KPMC) agents introduced in /8, 9/. The behaviour of a KPMC agent is encoded by a set of reaction rules. A reaction rule does not have a counterpart in other modelling frameworks, including in UML /10/.
Reactive behaviour of agents is the most dominant one in business and manufacturing domains. Reactive behaviour may also be combined with proactive behaviour, but this is not the topic of the present paper.
Each step of the use case represented in Table 1 is mapped to one or more reaction rules and/or activities. An activity may be started in response to an event by means of a reaction rule. Once an activity is started, the agent is in the corresponding activity state. An activity may trigger a reaction rule or subactivity through the implicit triggering event startOf(activity). Additionally, each activity is associated with another implicit triggering event endOf(activity) that may trigger other reaction rule or activity.
Figure 3. Visualization of activities and reaction rules by an activity diagram
An activity may also have a goal. For example, the goal of the activity “Process production order” in Figure 3 is ?ProductionOrder.isCompleted which is a semi-formal version of the goal of the corresponding use case stated in Table 1
(variables in the expressions as the one above are prefixed with a question mark). However, an important difference is that in the activity diagram the goal of the primary actor of the use case, the Sales Department, has been internalized by the actor in focus, the Production Department.
In a similar manner, the goal of the activity “Instantiate production plan” expressed in Object Constraint Language (OCL) of UML /10/ is ?ProductionOrder.productType.productionActivityType->forAll(productionActivity.isUnscheduled) which means that for each ProductionActivityType determined by the ProductType specified by the given production order exists an instance of ProductionActivity with the status isUnscheduled.
Activities are visualized as rectangles with rounded left and right sides, as shown in Figure 3. The triggering event startOf(activity) is represented by an empty circle with the outgoing arrow to the activity or reaction rule triggered by it. The triggering event endOf(activity) is modelled by drawing just the outgoing arrow from the activity to either the next activity or the reaction rule triggered by it.
A reaction rule is visualized as shown in the legend for Figure 3. If the composition of an activity is not specified, like in case of the activity “Register and s end scheduled production order” in Figure 3, the incoming arrow representing a status condition, the outgoing arrow denoting a status change, and the outgoing connector to an action type are directly connected to the rectangle representing the activity.
A reaction rule may have more than one triggering event: in such a case the rule is only triggered when all specified triggering events have occurred (without any required order). This allows to represent waiting for a message or an event. For example, after performing the activity “Request scheduling” in Figure 3, the Production Department enters into the activity state “Register scheduling” where it waits for the message from the corresponding Resource Unit with the scheduled start and end times of the production activity scheduled, and ends after receiving the message and registering scheduling by creating the corresponding status change.
When a status condition arrow originates in an object type for which no instance is determined by the triggering event, then the resulting action is performed for all current instances of that object type. A selection condition on the set of all instances may be defined by attaching a suitable OCL expression, referring to the attributes and associations of the object type, written within brackets to the status condition arrow. For example, the OCL expression forEach(?ProductionOrder.productType.productionActivityType->includes(self)) attached to the reaction rule R3 in Figure 3 means that the action prescribed by the rule is repeated for each ProductionActivityType determined by the ProductType specified by the given production order.
The fragment of the activity “Process production order” and its constituent activities represented in Figure 3 are modelled on the basis of six reaction rules, as follows.
R2: Upon receiving from the Sales Department a production order, the production order is entered into the knowledge base of the Production Department with the status isPreliminary, the corresponding instance of Product is created, and the activity “Process production order” is started.
R3: Upon the start of the subactivity “Instantiate production plan”, for each ProductionActivityType of the ProductType specified by the given ProductionOrder, an instance of ProductionActivity with the status isUnscheduled is created.
R4: Upon the start of the subactivity “Have production order scheduled”, for each ProductionActivity of the Product corresponding to the given ProductionOrder, the subactivity “Have production activity scheduled” is performed. R5: Waits for the message about the scheduling of the production activity from the corresponding Resource Unit, and registers the scheduling.
R6: Waits for the message about the acceptance of the production order from the Sales Department, registers the acceptance, and creates the commitment produceProduct of the Production Department towards the Sales Department. R7: Upon the start of the subactivity “Request performing”, for each ProductionActivity of the Product corresponding to the given ProductionOrder, the actual performing of the production activity is requested from the corresponding Resource Unit.
4 SIMULATION
For performing simulations with the models of the ceramic factory, we are in the process of implementing the models of the factory in the Java language. The object types of the problem domain represented in the agent diagram in Figure 1 are turned into the respective Java classes. The agents represented in the agent diagram in Figure 1 are transformed to the corresponding Java agents of the JADE agent platform described in /11/. In particular, activities of agents represented in activity diagrams like in Figure 3 are straightforwardly mapped to the corresponding behaviours of agents defined within the JADE framework. Reaction rules are as straightforwardly mapped to message handlers and other constructs invoking the behaviours.
With the help of the visual user interface, the user will, for example, be able to describe an instance of the ProductionOrder with its releaseDate, dueDate, quantity, and ProductType. Thereafter the system computes the preliminary
schedule and presents it to the user. We also plan to introduce the “performing” of the schedule by the agent-based simulation system and reactions to capacity and time conflicts resulting from it, as described in /16/. Later on, the system may be connected to the actual production environment where it would be used in creating production schedules.
5 CONCLUSIONS
We have demonstrated the feasibility of an agent-oriented approach for modelling and simulation of production environments by using an example of a ceramic factory. Within our approach, we have separated the Agent Layer, where the behaviour of agents is described, from the Object Layer, where the knowledge/information possessed by the agents is stored, and from the Implementation Layer. We understand the Object Layer in a wide sense of the term as either some relational, object-relational, or object-oriented database, or as some object-oriented framework such as COM? or CORBA?. The Implementation Layer provides lower-level implementation support for objects and agents.
We have based the modelling of business/manufacturing processes on the notion of reaction rule. Reaction rules have traditionally been modelled and implemented in the narrow context of (active) databases. We have adopted a broader view, and a more cognitive stance, by proposing to model and implement reaction rules as the “rules of behaviour” of business/manufacturing agents. We have also shown how to visualize reaction rules in Agent-Object-Relationship models.
With the agent-oriented approach to modelling and simulation of production environments, each agent is autonomous and does not know the decision logic of the others, as a rule. The decision logic is specified for each agent individually and not for the system of agents, as a whole. This comes closer to how the real world “works” than traditional approaches for modelling big systems, including UML /10/. In particular, activity diagrams of UML do not enable to model interactions between autonomous actors because they model interactions across actor boundaries as state changes of the system.
In addition to the case study of the ceramic factory, the methodology described in this paper has been used for modelling the problem domain and business processes of a fictious car rental company /12/, and for modelling the problem domain of electronic advertising in newspapers and the inter-enterprise business processes related to it /13/.
6 REFERENCES
1. Cockburn, A.: Goals and Use Cases. Journal of Object-Oriented Programming, September 1997.
2. Cockburn, A.: Using Goal-based Use Cases. Journal of Object-Oriented Programming, November/December
1997.
3. Wagner, G.: Agent-Oriented Enterprise and Business Process Modeling. In: Proceedings of the First
International Workshop on Enterprise Management and Resource Planning Systems (EMRPS’99), Venice, November 1999.
4. Wagner, G.: Agent-Oriented Analysis and Design of Organizational Information Systems. In: Barzdins, J.,
Caplinskas, A. (eds.): Databases and Information Systems. Proceedings of the Fourth IEEE International Baltic Workshop on Databases and Information Systems, 1–5 May 2000, Vilnius, Lithuania. Kluwer Academic Publishers, Boston Dordrecht London (2000).
5. Foundation for Intelligent Physical Agents (FIPA), https://www.wendangku.net/doc/d36773981.html,
6. Knowledge Query and Manipulation Language (KQML), https://www.wendangku.net/doc/d36773981.html,/kqml/
7. Singh, M.: An Ontology for Commitments in Multiagent Systems: Toward a Unification of Normative Concepts.
Artificial Intelligence and Law 7 (1999) 97-113.
8. Wagner, G.: Foundations of Knowledge Systems with Applications to Databases and Agents. Kluwer Academic
Publishers, Boston Dordrecht London (1998).
9. Wagner, G.: Vivid Agents - How they Deliberate, How They React, How They Are Verified. Extended version
of: Wagner, G.: A Logical And Operational Model of Scalable Knowledge- and Perception-Based Agents. In: Van de Velde, W., Perram. J. W. (eds.): Agents Breaking Away. Proceedings of MAAMAW'96. Lecture Notes in Artificial Intelligence, Vol. 1038. Springer-Verlag, Berlin Heidelberg New York (1996). Available at http://tmitwww.tm.tue.nl/staff/gwagner
10. Unified Modelling Language (UML), https://www.wendangku.net/doc/d36773981.html,/uml/
11. Bellifemine, F., Poggi, A., Rimassa, G.: Developing multi-agent systems with a FIPA-compliant agent
framework. Software – Practice and Experience 31 (2001) 103-128.
12. Taveter, K., Wagner, G.: Agent-Oriented Enterprise Modeling Based on Business Rules. In: Proceedings of the
20th International Conference on Conceptual Modeling (ER’2001), Yokohama, Japan, November 27-30, 2001.
Springer-Verlag, Berlin Heidelberg New York (2001).
13. Taveter, K., Wagner, G.: A multi paradigm methodology for modelling inter-enterprises business processes. In:
Proceedings of the 2nd International Workshop on Conceptual Modeling Approaches for e-Business, held in conjunction with the 20th International Conference on Conceptual Modeling (ER2001), Yokohama, Japan, November 2001. Springer-Verlag (forthcoming).
14. Singh, M.: An Ontology for Commitments in Multiagent Systems: Toward a Unification of Normative Concepts.
Artificial Intelligence and Law 7 (1999) 97-113.
15. Smith, S., Becker, M.: An Ontology for Constructing Scheduling Systems. Working Notes of 1997 AAAI
Symposium on Ontological Engineering. AAAI Press, 1997.
16. Smith, S.: Reactive Scheduling Systems. In: Brown, D.E., Scherer, W.T. (eds.): Intelligent Scheduling Systems.
Kluwer Press, 1995.
titlesec宏包使用手册
titlesec&titletoc中文文档 张海军编译 makeday1984@https://www.wendangku.net/doc/d36773981.html, 2009年10月 目录 1简介,1 2titlesec基本功能,2 2.1.格式,2.—2.2.间隔, 3.—2.3.工具,3. 3titlesec用法进阶,3 3.1.标题格式,3.—3.2.标题间距, 4.—3.3.与间隔相关的工具, 5.—3.4.标题 填充,5.—3.5.页面类型,6.—3.6.断行,6. 4titletoc部分,6 4.1.titletoc快速上手,6. 1简介 The titlesec and titletoc宏包是用来改变L A T E X中默认标题和目录样式的，可以提供当前L A T E X中没有的功能。Piet van Oostrum写的fancyhdr宏包、Rowland McDonnell的sectsty宏包以及Peter Wilson的tocloft宏包用法更容易些；如果希望用法简单的朋友，可以考虑使用它们。 要想正确使用titlesec宏包，首先要明白L A T E X中标题的构成，一个完整的标题是由标签+间隔+标题内容构成的。比如： 1.这是一个标题，此标题中 1.就是这个标题的标签，这是一个标签是此标题的内容，它们之间的间距就是间隔了。 1
2titlesec基本功能 改变标题样式最容易的方法就是用几向个命令和一系列选项。如果你感觉用这种方法已经能满足你的需求，就不要读除本节之外的其它章节了1。 2.1格式 格式里用三组选项来控制字体的簇、大小以及对齐方法。没有必要设置每一个选项，因为有些选项已经有默认值了。 rm s f t t md b f up i t s l s c 用来控制字体的族和形状2，默认是bf,详情见表1。 项目意义备注（相当于） rm roman字体\textrm{...} sf sans serif字体\textsf{...} tt typewriter字体\texttt{...} md mdseries(中等粗体)\textmd{...} bf bfseries(粗体)\textbf{...} up直立字体\textup{...} it italic字体\textit{...} sl slanted字体\textsl{...} sc小号大写字母\textsc{...} 表1:字体族、形状选项 bf和md属于控制字体形状，其余均是切换字体族的。 b i g medium s m a l l t i n y（大、中、小、很小） 用来标题字体的大小，默认是big。 1这句话是宏包作者说的，不过我感觉大多情况下，是不能满足需要的，特别是中文排版，英文 可能会好些！ 2L A T E X中的字体有5种属性：编码、族、形状、系列和尺寸。 2
ctex 宏包说明 ctex
ctex宏包说明 https://www.wendangku.net/doc/d36773981.html,? 版本号：v1.02c修改日期：2011/03/11 摘要 ctex宏包提供了一个统一的中文L A T E X文档框架，底层支持CCT、CJK和xeCJK 三种中文L A T E X系统。ctex宏包提供了编写中文L A T E X文档常用的一些宏定义和命令。 ctex宏包需要CCT系统或者CJK宏包或者xeCJK宏包的支持。主要文件包括ctexart.cls、ctexrep.cls、ctexbook.cls和ctex.sty、ctexcap.sty。 ctex宏包由https://www.wendangku.net/doc/d36773981.html,制作并负责维护。 目录 1简介2 2使用帮助3 2.1使用CJK或xeCJK (3) 2.2使用CCT (3) 2.3选项 (4) 2.3.1只能用于文档类的选项 (4) 2.3.2只能用于文档类和ctexcap.sty的选项 (4) 2.3.3中文编码选项 (4) 2.3.4中文字库选项 (5) 2.3.5CCT引擎选项 (5) 2.3.6排版风格选项 (5) 2.3.7宏包兼容选项 (6) 2.3.8缺省选项 (6) 2.4基本命令 (6) 2.4.1字体设置 (6) 2.4.2字号、字距、字宽和缩进 (7) ?https://www.wendangku.net/doc/d36773981.html, 1
1简介2 2.4.3中文数字转换 (7) 2.5高级设置 (8) 2.5.1章节标题设置 (9) 2.5.2部分修改标题格式 (12) 2.5.3附录标题设置 (12) 2.5.4其他标题设置 (13) 2.5.5其他设置 (13) 2.6配置文件 (14) 3版本更新15 4开发人员17 1简介 这个宏包的部分原始代码来自于由王磊编写cjkbook.cls文档类，还有一小部分原始代码来自于吴凌云编写的GB.cap文件。原来的这些工作都是零零碎碎编写的，没有认真、系统的设计，也没有用户文档，非常不利于维护和改进。2003年，吴凌云用doc和docstrip工具重新编写了整个文档，并增加了许多新的功能。2007年，oseen和王越在ctex宏包基础上增加了对UTF-8编码的支持，开发出了ctexutf8宏包。2009年5月，我们在Google Code建立了ctex-kit项目1，对ctex宏包及相关宏包和脚本进行了整合，并加入了对XeT E X的支持。该项目由https://www.wendangku.net/doc/d36773981.html,社区的开发者共同维护，新版本号为v0.9。在开发新版本时，考虑到合作开发和调试的方便，我们不再使用doc和docstrip工具，改为直接编写宏包文件。 最初Knuth设计开发T E X的时候没有考虑到支持多国语言，特别是多字节的中日韩语言。这使得T E X以至后来的L A T E X对中文的支持一直不是很好。即使在CJK解决了中文字符处理的问题以后，中文用户使用L A T E X仍然要面对许多困难。最常见的就是中文化的标题。由于中文习惯和西方语言的不同，使得很难直接使用原有的标题结构来表示中文标题。因此需要对标准L A T E X宏包做较大的修改。此外，还有诸如中文字号的对应关系等等。ctex宏包正是尝试着解决这些问题。中间很多地方用到了在https://www.wendangku.net/doc/d36773981.html,论坛上的讨论结果，在此对参与讨论的朋友们表示感谢。 ctex宏包由五个主要文件构成：ctexart.cls、ctexrep.cls、ctexbook.cls和ctex.sty、ctexcap.sty。ctex.sty主要是提供整合的中文环境，可以配合大多数文档类使用。而ctexcap.sty则是在ctex.sty的基础上对L A T E X的三个标准文档类的格式进行修改以符合中文习惯，该宏包只能配合这三个标准文档类使用。ctexart.cls、ctexrep.cls、ctexbook.cls则是ctex.sty、ctexcap.sty分别和三个标准文档类结合产生的新文档类，除了包含ctex.sty、ctexcap.sty的所有功能，还加入了一些修改文档类缺省设置的内容（如使用五号字体为缺省字体）。 1https://www.wendangku.net/doc/d36773981.html,/p/ctex-kit/
tabularx宏包中改变弹性列的宽度
tabularx宏包中改变弹性列的宽度\hsize 分类：latex 2012-03-07 21:54 12人阅读评论(0) 收藏编辑删除 \documentclass{article} \usepackage{amsmath} \usepackage{amssymb} \usepackage{latexsym} \usepackage{CJK} \usepackage{tabularx} \usepackage{array} \newcommand{\PreserveBackslash}[1]{\let \temp =\\#1 \let \\ = \temp} \newcolumntype{C}[1]{>{\PreserveBackslash\centering}p{#1}} \newcolumntype{R}[1]{>{\PreserveBackslash\raggedleft}p{#1}} \newcolumntype{L}[1]{>{\PreserveBackslash\raggedright}p{#1}} \begin{document} \begin{CJK*}{GBK}{song} \CJKtilde \begin{tabularx}{10.5cm}{|p{3cm} |>{\setlength{\hsize}{.5\hsize}\centering}X |>{\setlength{\hsize}{1.5\hsize}}X|} %\hsize是自动计算的列宽度，上面{.5\hsize}与{1.5\hsize}中的\hsize前的数字加起来必须等于表格的弹性列数量。对于本例，弹性列有2列，所以“.5+1.5=2”正确。 %共3列，总列宽为10.5cm。第1列列宽为3cm，第3列的列宽是第2列列宽的3倍，其宽度自动计算。第2列文字左右居中对齐。注意：\multicolum命令不能跨越X列。 \hline 聪明的鱼儿在咬钩前常常排祠再三& 这是因为它们要荆断食物是否安全&知果它们认为有危险\\ \hline 它们枕不会吃& 如果它们判定没有危险& 它们就食吞钩\\ \hline 一眼识破诱饵的危险，却又不由自主地去吞钩的& 那才正是人的心理而不是鱼的心理& 是人的愚合而不是鱼的恳奋\\
配合前面的ntheorem宏包产生各种定理结构
%=== 配合前面的ntheorem宏包产生各种定理结构,重定义一些正文相关标题===% \theoremstyle{plain} \theoremheaderfont{\normalfont\rmfamily\CJKfamily{hei}} \theorembodyfont{\normalfont\rm\CJKfamily{song}} \theoremindent0em \theoremseparator{\hspace{1em}} \theoremnumbering{arabic} %\theoremsymbol{} %定理结束时自动添加的标志 \newtheorem{definition}{\hspace{2em}定义}[chapter] %\newtheorem{definition}{\hei 定义}[section] %!!!注意当section为中国数字时，[sction]不可用！ \newtheorem{proposition}{\hspace{2em}命题}[chapter] \newtheorem{property}{\hspace{2em}性质}[chapter] \newtheorem{lemma}{\hspace{2em}引理}[chapter] %\newtheorem{lemma}[definition]{引理} \newtheorem{theorem}{\hspace{2em}定理}[chapter] \newtheorem{axiom}{\hspace{2em}公理}[chapter] \newtheorem{corollary}{\hspace{2em}推论}[chapter] \newtheorem{exercise}{\hspace{2em}习题}[chapter] \theoremsymbol{$\blacksquare$} \newtheorem{example}{\hspace{2em}例}[chapter] \theoremstyle{nonumberplain} \theoremheaderfont{\CJKfamily{hei}\rmfamily} \theorembodyfont{\normalfont \rm \CJKfamily{song}} \theoremindent0em \theoremseparator{\hspace{1em}} \theoremsymbol{$\blacksquare$} \newtheorem{proof}{\hspace{2em}证明} \usepackage{amsmath}%数学 \usepackage[amsmath,thmmarks,hyperref]{ntheorem} \theoremstyle{break} \newtheorem{example}{Example}[section]
Groff 应用
使用Groff 生成独立于设备的文档开始之前 了解本教程中包含的内容和如何最好地利用本教程，以及在使用本教程的过程中您需要完成的工作。 关于本教程 本教程提供了使用Groff(GNU Troff)文档准备系统的简介。其中介绍了这个系统的工作原理、如何使用Groff命令语言为其编写输入、以及如何从该输入生成各种格式的独立于设备的排版文档。 本教程所涉及的主题包括： 文档准备过程 输入文件格式 语言语法 基本的格式化操作 生成输出 目标 本教程的主要目标是介绍Groff，一种用于文档准备的开放源码系统。如果您需要在应用程序中构建文档或帮助文件、或为客户和内部使用生成任何类型的打印或屏幕文档(如订单列表、故障单、收据或报表)，那么本教程将向您介绍如何开始使用Groff以实现这些任务。 在学习了本教程之后，您应该完全了解Groff的基本知识，包括如何编写和处理基本的Groff输入文件、以及如何从这些文件生成各种输出。
先决条件 本教程的目标读者是入门级到中级水平的UNIX?开发人员和管理员。您应 该对使用UNIX命令行Shell和文本编辑器有基本的了解。 系统要求 要运行本教程中的示例，您需要访问运行UNIX操作系统并安装了下面这些软件的计算机(请参见本教程的参考资料部分以获取相关链接)： Groff。Groff分发版中包括groff前端工具、troff后端排版引擎和本教 程中使用的各种附属工具。 自由软件基金会将Groff作为其GNU Project中的一部分进行了发布，所 发布的源代码符合GNU通用公共许可证(GPL)并得到了广泛的移植，几乎对于所有的UNIX操作系统、以及非UNIX操作系统(如Microsoft?Windows?)都有相应 的可用版本。 在撰写本教程时，最新的Groff发布版是Version 1.19.2，对于学习本教 程而言，您至少需要Groff Version 1.17。 gxditview。从Version 1.19.2开始，Groff中包含了这个工具，而在以 前的版本中，对其进行了单独的发布。 PostScript Previewer，如ghostview、gv或showpage。 如果您是从源代码安装Groff，那么请参考Groff源代码分发版中的自述 文件，其中列举了所需的任何额外的软件，而在编译和安装Groff时可能需要 使用这些软件。 介绍Groff 用户通常在字处理软件、桌面发布套件和文本布局应用程序等应用程序环 境中创建文档，而在这些环境中，最终将对文档进行打印或导出为另一种格式。整个文档准备过程，从创建到最后的输出，都发生在单个应用程序中。文档通
TeX 使用指南(常见问题)
TeX 使用指南 常见问题（一） 1.\makeatletter 和\makeatother 的用法？ 答：如果需要借助于内部有\@字符的命令，如\@addtoreset，就需要借助于另两个命令 \makeatletter, \makeatother。 下面给出使用范例，用它可以实现公式编号与节号的关联。 \begin{verbatim} \documentclass{article} ... \makeatletter % '@' is now a normal "letter" for TeX \renewcommand\theequation{\thesection.\arabic{equation}} \@addtoreset{equation}{section} \makeatother % '@' is restored as a "non-letter" character for TeX \begin{document} ... \end{verbatim} 2.比较一下CCT与CJK的优缺点？ 答：根据王磊的经验，CJK 比CCT 的优越之处有以下几点： 1）字体定义采用LaTeX NFSS 标准，生成的DVI 文件不必像CCT 那样需要用patchdvi 处理后才能预览和打印。而且一般GB 编码的文件也不必进行预处理就可直接用latex 编译。2）可使用多种TrueType 字体和Type1 字体，生成的PDF 文件更清楚、漂亮。 3）能同时在文章中使用多种编码的文字，如中文简体、繁体、日文、韩文等。 当然，CCT 在一些细节上，如字体可用中文字号，字距、段首缩进等。毕竟CJK 是老外作的吗。 谈到MikTeX 和fpTeX, 应该说谈不上谁好谁坏，主要看个人的喜好了。MikTeX 比较小，不如fpTeX 里提供的TeX 工具，宏包全，但一般的情况也足够了。而且Yap 比windvi 要好用。fpTeX 是teTeX 的Windows 实现，可以说各种TeX 的有关软件基本上都包括在内。 3.中文套装中如何加入新的.cls文件？ 答：放在tex文件的同一目录下，或者miktex/localtexmf/tex/latex/下的某个子目录下，可以自己建一个。 4.怎样象第几章一样，将参考文献也加到目录？ 答：在参考文献部分加入 \addcontentsline{toc}{chapter}{参考文献}
listings 是专用于代码排版的 LaTeX宏包(及使用xltxtra进行中文支持)
listings 是专用于代码排版的 LaTeX宏包（及使用xltxtra进行中文支持） 分类：科研文献2012-10-17 11:25 1829人阅读评论(0) 收藏举报numbers文档测试floatc语言 listings是专用于代码排版的LaTeX 宏包，可对关键词、注释和字符串等使用不同的字体和颜色或颜色，也可以为代码添加边框、背景等风格。 1 基本用法 下面给出一份用于排版 C 语言HelloWorld程序代码的完整的LaTeX文档： \documentclass{article} \usepackage{listings} \begin{document} \begin{lstlisting}[language=C] int main(intargc, char ** argv) { printf("Hello world!\n"); return 0; } \end{lstlisting} \end{document} 注意，要使用 listings 宏包提供的语法高亮，需要xcolor宏包支持。 4 添加边框 listings 宏包为代码边框提供了很多风格，大体可分为带有阴影的边框与圆角边框。这里仅仅给出一个阴影边框的示例，至于其它边框风格，可查阅 listings宏包文档，里面给出了一些示例。 下面LaTeX源文档将为代码添加阴影边框，并将阴影设置为浅灰色：
\begin{lstlisting}[language={[ANSI]C}, keywordstyle=\color{blue!70}, commentstyle=\color{red!50!green!50!blue!50}, frame=shadowbox, rulesepcolor=\color{red!20!green!20!blue!20}] int main(intargc, char ** argv) { printf("Hello world!\n"); return 0; } \end{lstlisting} 5 添加行号 很多时候需要对文档中的代码进行解释，只有带有行号的代码才可以让解释更清晰，因为你只需要说第 x 行代码有什么作用即可。如果没有行号，那对读者而言就太残忍了，他们不得不从你的文字叙述中得知行号信息，然后去一行一行的查到相应代码行。 listings宏包通过参数 numbers 来设定行号，该参数的值有两个，分别是 left与 right，表示行号显示在代码的左侧还是右侧。下面为带有边框的代码添加行号，并设置行号字体为 \tiny： \begin{lstlisting}[language={[ANSI]C}, numbers=left, numberstyle=\tiny, keywordstyle=\color{blue!70}, commentstyle=\color{red!50!green!50!blue!50}, frame=shadowbox, rulesepcolor=\color{red!20!green!20!blue!20}] int main(intargc, char ** argv) { printf("Hello world!\n"); return 0; } \end{lstlisting} 6 全局设置 上面所给的各个示例中，lstlisting 环境后面尾随了很多参数，要是每使用一次lstlisting 环境就要设置这么多参数，那就没什么意思了。 可以使用 \lstset命令在LaTeX源文档的导言区设定好lstlisting 环境所用的公共参数，如下： \documentclass{article} \usepackage{listings}
浮动体环境下利用caption宏包制定标题
浮动体环境下利用caption宏包制定标题 Axel Sommerfeldt Released by ChinaT E X Documentation Workshop. April29,2011 Maker:Clark Ma Translator:Clark Ma
浮动体环境下利用caption宏包制定标题? Axel Sommerfeldt caption@sommerfee.de 2008/04/06 摘要 本宏包提供了在如figure和table等浮动体中定制标题的功能，并且能和许多其他宏包结合使用。 请注意：许多文档类已经预设好了制定标题的选项和命令。如果这些已有的预设选项对你已经很够用，那么就没有再使用caption宏包的必要。不过如果你 仅仅是对\captionof命令感兴趣，那么加载使用一个小capt-of宏包就是经常很 够用的。 引言 在标准的L A T E X文档类中，标题并没有得到应有的注意。简单的排版如普通的段落在下面这种情况下和正文之间的区别是不明显的： Figure1:White sand beaches.The pink smoothness of the conch shell.A sea abundant with possibilities.Duty-free shops?lled with Europe’s?nest gifts and perfumes.Play your favorite game of golf amidst the tropical greens on one of the many championship courses. 这种情况有必要改成这样，比如，使标题比正文略小一点，增加版口，使用和文章标题相同的字体族和字样来排印标题标签等，这将会好一些。正如下面这个：Figure2–White sand beaches.The pink smoothness of the conch shell.A sea abundant with possibilities.Duty-free shops?lled with Europe’s?nest gifts and perfumes.Play your favorite game of golf amidst the tropical greens on one of the many championship courses. 你可以利用这个宏包里的多种标题格式选项轻松地做到上述的效果，不过你也可以同样自由地定义你想要的格式。 i 请注意caption宏包仅仅是控制标题的效果。它并不能控制标题的位置。（但是你可以利用其他的如?oatrow宏包来控制标题的位置。[8].) ?本宏包版本号为4.8.2，最后增订于2008/04/06 1
xpinyin 宏包
xpinyin宏包 李清 sobenlee@https://www.wendangku.net/doc/d36773981.html, 2014/06/25v1.9 1简介 xpinyin是一个L A T E X宏包，提供了为汉字自动注音的功能。 2基本用法 xpinyin支持采用GBK和UTF-8编码的T E X源文件，建议总是使用UTF-8。如果使用L A T E X 或pdfL A T E X的编译方式，则根据编码的情况，xpinyin依赖CJK或者CJKutf8宏包。如果使用X?L A T E X，则依赖xeCJK宏包。如果它们没有在xpinyin之前被载入，xpinyin将根据编译方式自动选择，L A T E X或pdfL A T E X将使用CJKutf8。 xpinyin还依赖l3kernel和l3packages，使用(pdf)L A T E X下的GBK编码时，还将依赖xCJK2uni。 需要注意的是，xpinyin缺省将拼音的字体设置为与文档的主字体（\normalfont）相同，所以为了保证声调字母的正确输出，应该选用合适的西文主字体。也可以通过将在下一节介绍的?font?选项来单独设置拼音的字体。 X?L A T E X下的简单示例： \documentclass{article} \usepackage{xeCJK} \usepackage{xpinyin} \setmainfont{CMU Serif} \setCJKmainfont{SimSun} \begin{document} \xpinyin*{汉语拼音示例} \end{document}(pdf)L A T E X下的简单示例： \documentclass{article} \usepackage{CJKutf8} \usepackage{xpinyin} \usepackage[T1]{fontenc} \usepackage{lmodern} \begin{document} \begin{CJK}{UTF8}{gbsn} \xpinyin*{汉语拼音示例} \end{CJK} \end{document} 运行上述示例要求系统安装了设置的字体，源文件用UTF-8编码保存，使用相应的编译方式。 xpinyin可以与ctex宏包或文档类共同使用，使用方式与上面类似。 3用户手册 \begin{pinyinscope}[?options?] ..... \end{pinyinscope} 为pinyinscope环境中的汉字自动注音。例如 1\begin{pinyinscope} 2列位看官：你道此书从何而来？说起根由，虽近荒唐，细按则深有趣味。 3待在下将此来历注明，方使阅者\xpinyin{了}{liao3}然不惑。 4\end{pinyinscope} liè 列wèi位kàn看guān 官：nǐ你dào道cǐ此shū书cóng从hé何ér而lái来？shuō说qǐ起gēn根yoú由，suī虽jìn近huāng 荒táng唐，xì细àn按zé则shēn深yoǔ有qù趣wèi味。dài待zài在xià下jiāng将cǐ此lái来lì历zhù注míng明，fāng方shǐ使 yuè 阅zhě者liǎo了rán然bù不huò惑。 pinyinscope 1
LaTeX部分宏包介绍
\usepackage{geometry} % 利用geometry 可以很方便的设置页面的大小。 \usepackage{fancyhdr} % 用fancyhdr 来设置页眉和页脚十分方便，而且可以在配合CCT、CJK来设置中文的页眉等。 \usepackage{fancyvrb} % 用来得到一些加框的列举环境 \usepackage{fancybox} % 提供了\shadowbox, \doublebox, \ovalbox 和\Ovalbox 四个命令来生成不同形状的盒子。 \usepackage{amsmath,amsfonts,amssymb,graphicx} % EPS 图片支持 \usepackage{subfigure} % 使用子图形 \usepackage{indentfirst} % 中文段落首行缩进 \usepackage{bm} % 公式中的粗体字符（用命令\boldsymbol） \usepackage{multicol} % 正文双栏 \usepackage{picins} % 图片嵌入段落宏包比如照片 \usepackage{abstract} % 2栏文档，一栏摘要及关键字宏包 \usepackage{anysize} % 对于像book 等双面版式来说，这里的left 和right 再奇偶页会 互换。 \usepackage{hyperref} % 文献引用的宏包 \usepackage{listings}\lstloadlanguages{C,C++,matlab,mathematica} %程序清单关键字宏 包 \usepackage{color} % 可以产生有颜色的符号 \usepackage{units} % 用于美化单位及分式 \usepackage{tabularx} % 用于灵活地控制表格的生成 \usepackage{mathrsfs} % 用于产生一种数学用的花体字 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 关于各个宏包的说明。 % CJK宏包中重要的命令为： % \CJKcaption{GB} 章节标题为中文 % \CJKfamily{hei}{} %song, fs, kai, hei, songsl, fssl, kaisl, heisl % CTEX中文套装中定义了六种中文字体，分别是 % song, 宋体 % fs, 仿宋 % kai, 楷书 % hei, 黑体%以上这四种字体都是可以用的，并且还有对应的斜体可用（\it 即可） % li, 隶书%但看来这个是不能用的，怎样解决我还不知道，还不懂怎样安装字体 % yuan, 幼圆%这个也不能用 % geometry宏包重要的命令为： % \geometry{height=10in,a4paper,body={14cm,21cm}} %具体内容由自己改写 % fancyhdr宏包重要的命令为： % 如下面所用到的页眉和页脚的定义，很典型的 % fancyvrb宏包重要的命令为： % 很多，应用方法很灵活。具体查阅其说明文档 % fancybox宏包重要的命令为： % \shadowbox{}和\doublebox{}，括号里面可以包含一个minipage环境，可以含一个图片 % amsmath,amsfonts,amssymb,graphicx宏包重要的命令为： % 这是一组非常重要的包，最重要的几个命令为：
tex范例
10月22日 一个比较好的Latex范例 由于用了一些和latex不兼容的宏包（pdfpages，主要用来加发表的文章做附件），只能用padlatex进行编译了（eps图片也要改为pdf图片）。 中文需要自己的宏包。 文中有些说明没有及时更改。 参数有些改了。有些％后的自己可以选择。 生成的pdf文件字体为cmr12，acrobat可以修改。还没找到用times roman字体的方法（latex 编译方法倒可以实现，就是宏包冲突，才改为paflatex编译）。 本主文件用pdflatex，bibtex，pdflatex，pdflatex编译通过。当然需要每部分的tex文件都齐全了。 希望对大家有所帮助。 \documentclass[a4paper,12pt,oneside]{book} \pdfoutput = 1 \usepackage{geometry} %页面宏包 \geometry{a4paper,left=4cm, right=2.5cm, top=2.5cm, bottom=2.5cm} %页面设置 \usepackage{amsmath} % AMS 数学公式等 \usepackage{amssymb} % AMS 数学字库 \usepackage{fleqn}%公式对齐用 \setlength{\mathindent}{2em}%公式对齐用 \usepackage{textcomp} %欧元等符号,摄氏度用到\textcelsius~%不能用在公式环境 %\usepackage{times} % Times New Roman字体 %\usepackage[mtbold,mtpluscal,mtplusscr]{mathtime} %用mathtime 宏包来把数学环境中的字体都变成Times New Roman 字体 \usepackage[final]{pdfpages}%插入pdf文件 \usepackage{verbatim} %插入pdf文件 \usepackage{multicol} %要生成单双列混合的分栏格式 \usepackage{glossary} %生成术语表的宏包 %页眉页脚%%%%%%%%%%%%%%%%%% %\pagestyle{plain} \usepackage{fancyhdr} %页眉页脚 \pagestyle{fancy}%页眉页脚式样 %\renewcommand{\chaptermark}[1]{% %\markboth{\chaptername %\ \thechapter.\ #1}{}} \renewcommand{\chaptermark}[1]{% \markboth{#1}{}} \renewcommand{\sectionmark}[1]{} %\renewcommand{\sectionmark}[1]{\markright{\thesection.\ #1}}
写给LATEX类和宏包作者
L A T E X2ε Copyright c 1995–1998The L A T E X3Project :laughcry[laughcry2002@https://www.wendangku.net/doc/d36773981.html,] All rights reserved 12March1999 Contents 1 2 1.1 L A T E X2ε (2) 1.2 (3) 1.3 (3) 1.4 (4) 2 4 2.1 (4) 2.2 ‘docstrip’ ‘doc’ (5) 2.3 ? (5) 2.4 (5) 2.5 (6) 2.6 (De?ning text and math characters) (6) 2.7 (General style) (7) 3 / (The structure of a class or package)9 3.1 (Identi?cation) (10) 3.2 (Using classes and packages) (11) 3.3 (Declaring options) (12) 3.4 (A minimal class?le) (13) 3.5 (Example:a local letter class) (14) 3.6 (Example:a newsletter class) (14) 4 / (Commands for class and package writers)16 4.1 (Identi?cation) (16) 4.2 (Loading?les) (17) 4.3 (Option declaration) (18) 4.4 (Commands within option code) (18) 4.5 (Moving options around) (19) 1
latex编写表格
array 标准LaTeX 提供有array 和tabular 两个制表环境，它们的完整格式如下： \begin{array}[表格位置]{列样式} \end{array} \begin{tabular}[表格位置]{列样式} \end{tabular} \begin{tabular*}{表格总宽度}[表格位置]{列样式} \end{tabular*} 这两个环境的选项和参数定义是相同的，不过array 主要用于数组矩阵的排版，且只能用在数学环境中，如equation 等。 array 宏包扩展了 array 和tabular 环境功能，主要增加和增强了列样式选项，甚至可编程定义新的列样式；还增加了许多细部微调功能，如改变垂直表格线的粗细和自动调整表格间隙等。使用该宏包可以排印出外形美观、功能丰富的表格。 该宏包没有任何选项，扩展后的两个环境的列样式选项： 选项说明 l该列左对齐排列 c该列居中排列 r该列右对齐排列 p{列宽}设置该列宽度，文本顶对齐 @{声明}该列每行插入声明中文本 m{列宽}设置该列宽度，文本居中对齐 b{列宽}设置该列宽度，文本底对齐 >{声明}声明可以是命令或插入列元素之前的文本 <{声明}声明可以是命令或插入列元素之后的文本 |列边或列间加入一条垂直线 !{声明}用声明要求的样式取代列间垂直线
应用举例： 列样式还可设置为：>{\setlength{\parindent}{26pt}}p{列宽}，对该列文本行或段落缩排。 源文件 Frank Mittelbach et al booktabs 它定义了三条划线命令：\toprule、\midrule 和\bottomrule，可分别对表格顶部、中部和底部使用不同粗细的水平线，见下例：
natbib宏包快速参考手册
Reference sheet for natbib usage (Describing version8.31b from2010/09/13) For a more detailed description of the natbib package,L A T E X the source?le natbib.dtx. Overview The natbib package is a reimplementation of the L A T E X\cite command,to work with both author–year and numerical citations.It is compatible with the standard bibliographic style?les,such as plain.bst,as well as with those for harvard,apalike,chicago,astron,authordate,and of course natbib. Loading Load with\usepackage[options]{natbib}.See list of options at the end. Replacement bibliography styles I provide three new.bst?les to replace the standard L A T E X numerical ones: plainnat.bst abbrvnat.bst unsrtnat.bst Basic commands The natbib package has two basic citation commands,\citet and\citep for textual and parenthetical citations,respectively.There also exist the starred versions\citet*and\citep*that print the full author list,and not just the abbreviated one.All of these may take one or two optional arguments to add some text before and after the citation. \citet{jon90}?Jones et al.(1990) \citet[chap.~2]{jon90}?Jones et al.(1990,chap.2) \citep{jon90}?(Jones et al.,1990) \citep[chap.~2]{jon90}?(Jones et al.,1990,chap.2) \citep[see][]{jon90}?(see Jones et al.,1990) \citep[see][chap.~2]{jon90}?(see Jones et al.,1990,chap.2) \citet*{jon90}?Jones,Baker,and Williams(1990) \citep*{jon90}?(Jones,Baker,and Williams,1990) Multiple citations Multiple citations may be made by including more than one citation key in the\cite command argument. \citet{jon90,jam91}?Jones et al.(1990);James et al.(1991) \citep{jon90,jam91}?(Jones et al.,1990;James et al.1991) \citep{jon90,jon91}?(Jones et al.,1990,1991) \citep{jon90a,jon90b}?(Jones et al.,1990a,b) 1
xeCJK 中文手册
xeCJK宏包 孙文昌 2008年6月10日 1简 xeCJK是一个XeLaTeX宏包，用于排版CJK文字，包括字体选择、标点控制等。提供四种标点处理方式：全部全角式、全部半角式、开明式、CCT格式。 全角标点 计算机（computer/calculation machine）是总称，一般在学术性或正式场合使用。在通常用语中，计算机一般指电子计算机中用的个人电脑。计算机是一种能够按照指令对各种数据和信息进行自动加工和处理的电子设备。它由多个零配件组成，如中央处理器、主板、内存、电源、显卡等。接收、处理和提供数据的一种装置，通常由输入输出设备、存储器、运算和逻辑部件以及控制器组成；有模拟式、数字式及混合式三种类型。 半角标点 计算机（computer/calculation machine）是总称，一般在学术性或正式场合使用。在通常用语中，计算机一般指电子计算机中用的个人电脑。计算机是一种能够按照指令对各种数据和信息进行自动加工和处理的电子设备。它由多个零配件组成，如中央处理器、主板、内存、电源、显卡等。接收、处理和提供数据的一种装置，通常由输入输出设备、存储器、运算和逻辑部件以及控制器组成；有模拟式、数字式及混合式三种类型。 开明 计算机（computer/calculation machine）是总称，一般在学术性或正式场合使用。在通常用语中，计算机一般指电子计算机中用的个人电脑。计算机是一种能够按照指令对各种数据和信息进行自动加工和处理的电子设备。它由多个零配件组成，如中央处理器、主板、内存、电源、显卡等。接收、处理和提供数据的一种装置，通常由输入输出设备、存储器、运算和逻辑部件以及控制器组成；有模拟式、数字式及混合式三种类型。 CCT 计算机（computer/calculation machine）是总称，一般在学术性或正式场合使用。在通常用语中，计算机一般指电子计算机中用的个人电脑。计算机是一种能够按照指令对各种数据和信息进行自动加工和处理的电子设备。它由多个零配件组成，如中央处理器、主板、内存、电源、显卡等。接收、处理和提供数据的一种装置，通常由输入输出设备、存储器、运算和逻辑部件以及控制器组成；有模拟式、数字式及混合式三种类型。 对于中英文混排，允许在非标点汉字和英文字母(a-z,A-Z)间断行。支持自动切换中英文字体。