当然要有一定的汇编基础：
PDFLib虚拟文件系统(PVF)允许客户端直接通过内存提供数据。这可以提高效率，特别是当从数据库中读取数据时，或者是客户端在内存中已具备需要的数据。
PVF是建立在命名的虚拟只读文件的基础上的。可以通过API函数象操作正常的文件一样使用，甚至可以在UPR配置文件中使用。虚拟文件名可以由客户程序按任意方式生成。显然，虚拟文件名必须避免与实际磁盘文件冲突。由于这个原因，推荐使用以下的层次命名规范（filename是指由客户程序指定的在作用域内唯一的文件）。同时，推荐使用标准的文件名后缀。
栅格图象文件：/pvf/image/filename
字形文件：/pvf/font/filename
ICC profiles: /pvf/iccprofile/filename
编码和代码页：/pvf/codepage/filename
PDF文档；/pvf/pdf/filename
PDFLib查找命名文件时，首先检查文件名是否指向现有的虚拟文件，然后才试图打开硬盘上的文件。
虚拟文件的生命周期。一些函数使用虚拟文件中的全部数据，另外一些，可能仅读取文件的一部分，剩余部分在其它时间使用。由于这个原因，必须考虑虚拟文件的生命周期。PDFLib为每个虚拟文件加一个内部的锁，直到文件不再需要时才解锁。除非客户显式请求复制数据(使用PDF_create_pvf()函数的复制选项)，虚拟文件的内容只能被修改、删除或释放（当不再被PDFLib锁定时）。当调用PDF_删除()时，PDFLib自动删除所有的虚拟文件。然而，实际的文件内容（虚拟文件中的数据）必须由客户程序来释放。
不同的管理策略 PVF支持不同的方法对虚拟文件进行管理。管理规则基于这样一个事实，PDFLib也许需要在调用以虚拟文件名为参数的函数后存取虚拟文件的内容,但决不会在调用PDF_close()之后在存取文件内容。注意，调用PDF_删除_pvf()并不会释放实际的文件内容（除非提供了copy选项），而是释放用于管理PVF文件名称的数据结构。这就产生了以下的策略：
最小化内存消耗：推荐在调用接受虚拟文件名称的API之后或者是调用PDF_close()之后立即调用PDF_删除_pvf()。第二个调用是必需的，因为PD
FLib也许仍然需要存取数据，所以第一个调用可能无法接除锁定。有些情
况下，第一次调用已经释放了数据，但第二次调用不会造成任何伤害。客
户程序只有在PDF_删除_pvf()成功的情况下，才会释放文件数据。
通过重用虚拟文件优化性能：一些客户程序也许希望在一系列的文档输出中重复使用某些数据（例如：字体定义），从而避免多次重复创建/删除相同的文件内容。在这种情况下，建议在所有使用虚拟文件的PDF文档输出完成前，不要调用PDF_删除_pvf()。
懒人编程：如果内存消耗影响不大的话，客户程序可以选择不调用PDF_删除_pvf()。PDFLib在PDF_删除()中会内部删除所有未释放的虚拟文件。
在所有的情况下，客户程序只有在PDF_删除_pvf()调用成功或PDF_删除()调用之后才可以释放相应的数据。
我在别处看的，现在属于转发。
