【封面设计软件】制作封面使用什么软件比较好啊我想问下制作封面...
用pixlr比较好,这个软件是浓重风格的,可以加字,还有多种贴纸、叠加款式、调节功能,我最喜欢的是双重曝光和历史笔刷,双重曝光就是直接往底图上加图片,还有多种模式可以选择,比如去掉白色部分(这样图片就是无背景的了,可以加网站图标上去)等等甚至还可以做花底字,而历史笔刷就是可以把上一步的操作擦去一部分,比如你上一步双重曝光想加一个人物,但是人物背景太花哨你去不掉,就可以用历史笔刷把背景去掉,而且个人很喜欢这个软件的叠加功能,可以添加很多特效,然后唯一的缺点就是字体都是英文的,中文字体只能调节粗细,不过这不是问题,稍后我再告诉你解决方法。
谁知道怎样用电脑制作(设计)书的封面?要下载什么软件吗?
Photoshop是adobe公司推出的图形图像设计与处理软件,通过PS我们可以进行美术设计与制作。
大家会否对书籍、报刊等封面的设计感兴趣呢?下面我将以《扬帆》16K的封面为例,向大家介绍如何在PS中制作封面。
希望通过我的简单讲述,让大家了解其制作的一般过程。
下面我将介绍整个制作过程中的基本环节和要点,至于其中的细节设计和美化操作,在这里不多赘述,比如,特效文字、图像等等。
首先,按照封面需求新建一个图像。
《扬帆》是16K(185mm*260mm)的封面,所以在新建图像前,首先计算封面的尺寸;方法如下:封面一般包括封面、封底、和书脊;《扬帆》宽度=封面宽度+书脊厚度+封底宽度=185mm+185mm+2mm=372mm;高度=260mm;此为封面的实际大小,但在真正设计过程中我们一般需要在四边各增加3mm(也叫“出血”尺寸),所以至此封面的总尺寸为378mm*266mm。
新建图像时如图1进行设置,高为26.6cm,宽为37.8cm,分辨率为300,模式设置为RGB颜色,以方便编辑;因为在PS中很多功能必须在RGB颜色模式下进行操作,比如一些滤镜的功能。
我们可以在RGB颜色模式下完成后,再将其转化成CMYK模式(适应印刷的要求)。
其次,建立图像后,在视图→标尺使在图像窗口显示标尺,再在视图→新参考线,标出封底、封面、书脊和出血的位置,如图2所示。
第三,我们在封面、封底的相应位置添加素材图像及特效文字,如:报刊名称,出版单位,特效图片等,《扬帆》的书脊太薄,插入素材就免了。
这一步操作相当的灵活,按照设计者的思想及要求,所用到的PS功能各不相同,你可以先处理好一张特效图片然后置入图像;也可以先置入图像,再添加特效;一切就按设计者你的意思办了! 第四,就是把封面图像转换成CMYK模式。
方法:选择图像→模式→√CMYK颜色 ,即实现转化。
第五,保存图像;输出为TIF或EPS格式,因为出片时EPS和TIF格式的图像可以实现直接发出胶片。
保存TIF之前,最好先导出一个原文件,防止后天不满,方便修改。
这是使用PS的一个良好习惯! 最后,封面制作完成以后,将图像复制到连接有照排机的电脑上,通过发排软件进行4色出片。
关于这一步操作,有机会的同学可以到出版社去看看! 其实,正规的封面制作不单单使用PS,即使是我们的《扬帆》封面,也是由网络部的同学设计初稿,再拿到出版社进行修改!这其中就涉及到PageMaker-一个专业的排版处理软件。
所以说,想用PS设计一个良好的封面,还需要配合其他的软件来实现!OK,希望通过本文的介绍,新一期的《扬帆》封面能够采用你的作品!谢谢!! 编辑图片,可以使用photoshop软件,利用其中的层可以在图或照片之上罗列图或照片,以及添加文字。
最后设置打印时的页面。
如果是出版发行,建议还是请专业设计者设计比较好。
文档的软件设计说明
软件设计阶段结束后要交付软件设计说明书。
它的前半部分在概要设计后完成,后半部分在详细设计后写出。
设计说明书用于双重目的:对于编程和测试,它提供指南;软件交付使用后,为维护人员提供帮助。
软件设计说明书的框架和内容如下:(1)概述。
描述设计工作总的范围,包括系统目标、功能、接口等。
(2)系统结构。
用软件结构图说明本系统的模块划分,扼要说明每个模块的功能,按层次给出各模块之间的控制关系。
(3)数据结构及数据库设计。
对整个系统使用的数据结构及数据库进行设计,包括概念结构设计、逻辑结构设计和物理设计。
用相应的图形和表格把设计结果描述出来。
(4)接口设计。
设计人机界面,说明向用户提供的命令以及系统的返回信息;设计外部接口,说明本系统与外界的所有接口信息,包括软件与硬件之间的接口、本系统与支持软件之间的接口关系。
(5)模块设计。
按模块功能详细描述每个模块的流程及数据结构。
请问用软件什么制作封面好
面向对象软件设计说明书模板 1 概述 1.1 系统简述 对系统要完成什么,所面向的用户以及系统运行的环境的简短描述,这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标 这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。
同时,对于非功能性的需求例如性能、可用性等,亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何,务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分,将解释设计是怎么来实现这些的。
1.3 参考资料 列出本文档中所引用的参考资料。
(至少要引用需求规格说明书) 1.4 修订版本记录 列出本文档修改的历史纪录。
必须指明修改的内容、日期以及修改人。
2 术语表 对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。
3 用例 此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。
4 设计概述 4.1 简述 这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose) 4.2 系统结构设计 这部分要求提供高层系统结构的描述,使用方框图来显示主要的组件及组件间的交互。
最好是把逻辑结构同物理结构分离,对前者进行描述。
别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构 4.2.2 子系统1结构 4.2.3 子系统2结构 4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述,此处不用再重复,可以指引读者参考需求说明。
如果系统提供了对其它系统的接口,比如说从其它软件系统导入/导出数据,必须在此说明。
4.4 约束和假定 描述系统设计中最主要的约束,这些是由客户强制要求并在需求说明书写明的。
说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助,那么系统可能还受到其它的约束。
这种情况下,要求清楚地描述与本系统有交互的软件类型(比如某某某数据库软件,某某某EMail软件)以及这样导致的约束(比如只允许纯文本的Email)。
实现的语言和平台也会对系统有约束,同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束,简要地描述你的想法思路,经过怎么样的权衡,为什么要采取这样的设计等等。
5 对象模型 5.1 系统对象模型 提供整个系统的对象模型,如果模型过大,按照可行的标准把它划分成小块,例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢? 在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。
要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数(一对一、一对多还是多对多,0..1,*,1..*)。
聚合和继承关系必须清楚地确定下来。
每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述 在这个部分叙述每个对象的细节,它的属性、它的方法。
在这之前必须从逻辑上对对象进行组织。
你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。
在系统对象模型中简要的描述它的用途、约束(如只能有一个实例),列出它的属性和方法。
如果对象是存储在持久的数据容器中,标明它是持久对象,否则说明它是个临时对象(transient object)。
对每个对象的每个属性详细说明:名字、类型,如果属性不是很直观或者有约束(例如,每个对象的该属性必须有一个唯一的值或者值域是有限正整数等)。
对每个对象的每个方法详细说明:方法名,返回类型,返回值,参数,用途以及使用的算法的简要说明(如果不是特别简单的话)。
如果对变量或者返回值由什么假定的话,Pre-conditions和Post-conditions必须在此说明。
列出它或者被它调用的方法需要访问或者修改的属性。
最后,提供可以验证实现方法的测试案例。
6.1 子系统1中的对象 6.1.1 对象:对象1 用途: 约束: 持久性: 属性描述: 1. 属性:属性1 类型: 描述: 约束: 2. 属性:属性2 方法描述: 1. 方法:方法1 返回类型: 参数: 返回值: Pre-Condition: Post-Condition: 读取/修改的属性: 调用的方法: 处理逻辑: 测试例:用什么参数调用该方法,期望的输出是什么…… 7 动态模型 这部分的作用是描述系统如何响应各种事件。
例如,可以建立系统的行为模型。
一般使用顺序图和状态图。
确定不同的场景(Scenario)是第一步,不需要确定所有可能的场景,但是必须至少要覆盖典型的系统用例。
不要自己去想当然地创造场景,通常的策略是描述那些客户可以感受得到的场景。
7.1 场景(Scenarios) 对每个场景做一则条目,包括以下内容: 场景名:给它一个可以望文生义的名字 场景描述:简要叙述场景是干什么的以及发生的动作的顺序。
顺序图:描述各种事件及事件发生的相对时间顺序。
...
说明书设计要用什么软件
面向对象软件设计说明书模板 1 概述 1.1 系统简述 对系统要完成什么,所面向的用户以及系统运行的环境的简短描述,这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标 这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。
同时,对于非功能性的需求例如性能、可用性等,亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何,务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分,将解释设计是怎么来实现这些的。
1.3 参考资料 列出本文档中所引用的参考资料。
(至少要引用需求规格说明书) 1.4 修订版本记录 列出本文档修改的历史纪录。
必须指明修改的内容、日期以及修改人。
2 术语表 对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。
3 用例 此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。
4 设计概述 4.1 简述 这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose) 4.2 系统结构设计 这部分要求提供高层系统结构的描述,使用方框图来显示主要的组件及组件间的交互。
最好是把逻辑结构同物理结构分离,对前者进行描述。
别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构 4.2.2 子系统1结构 4.2.3 子系统2结构 4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述,此处不用再重复,可以指引读者参考需求说明。
如果系统提供了对其它系统的接口,比如说从其它软件系统导入/导出数据,必须在此说明。
4.4 约束和假定 描述系统设计中最主要的约束,这些是由客户强制要求并在需求说明书写明的。
说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助,那么系统可能还受到其它的约束。
这种情况下,要求清楚地描述与本系统有交互的软件类型(比如某某某数据库软件,某某某EMail软件)以及这样导致的约束(比如只允许纯文本的Email)。
实现的语言和平台也会对系统有约束,同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束,简要地描述你的想法思路,经过怎么样的权衡,为什么要采取这样的设计等等。
5 对象模型 5.1 系统对象模型 提供整个系统的对象模型,如果模型过大,按照可行的标准把它划分成小块,例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢? 在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。
要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数(一对一、一对多还是多对多,0..1,*,1..*)。
聚合和继承关系必须清楚地确定下来。
每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述 在这个部分叙述每个对象的细节,它的属性、它的方法。
在这之前必须从逻辑上对对象进行组织。
你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。
在系统对象模型中简要的描述它的用途、约束(如只能有一个实例),列出它的属性和方法。
如果对象是存储在持久的数据容器中,标明它是持久对象,否则说明它是个临时对象(transient object)。
对每个对象的每个属性详细说明:名字、类型,如果属性不是很直观或者有约束(例如,每个对象的该属性必须有一个唯一的值或者值域是有限正整数等)。
对每个对象的每个方法详细说明:方法名,返回类型,返回值,参数,用途以及使用的算法的简要说明(如果不是特别简单的话)。
如果对变量或者返回值由什么假定的话,Pre-conditions和Post-conditions必须在此说明。
列出它或者被它调用的方法需要访问或者修改的属性。
最后,提供可以验证实现方法的测试案例。
6.1 子系统1中的对象 6.1.1 对象:对象1 用途: 约束: 持久性: 6.1.1.1 属性描述: 1. 属性:属性1 类型: 描述: 约束: 2. 属性:属性2 6.1.1.2 方法描述: 1. 方法:方法1 返回类型: 参数: 返回值: Pre-Condition: Post-Condition: 读取/修改的属性: 调用的方法: 处理逻辑: 测试例:用什么参数调用该方法,期望的输出是什么…… 7 动态模型 这部分的作用是描述系统如何响应各种事件。
例如,可以建立系统的行为模型。
一般使用顺序图和状态图。
确定不同的场景(Scenario)是第一步,不需要确定所有可能的场景,但是必须至少要覆盖典型的系统用例。
不要自己去想当然地创造场景,通常的策略是描述那些客户可以感受得到的场景。
7.1 场景(Scenarios) 对每个场景做一则条目,包括以下内容: 场景名:给它一个可以望文生义的名字 场景描述:简要叙述场景是干什么的以及发生的动作的顺序。
顺序图:描述各种事件及事件发生的...