車忱 機械工業出版社
科技圖書是圖書市場的重要組成部分。科技圖書質量的高低,不僅反映了一個國家的科技水平,更直接影響科學研究和各行各業的生產。不可否認的是,由于市場競爭激烈,圖書出版周期縮短,導致科技圖書質量有所下降,引起讀者不滿。國家目前非常重視圖書質量工作,每年不僅嚴格監督各出版社的質量檢查工作,還組織出版社的互查工作。圖書質量是出版社的生命線,要保證圖書質量,沒有捷徑可走,圖書編輯必須認真加工和審讀稿件。本文總結了科技圖書和稿件中的一些典型錯誤,希望編輯同人在工作中引以為戒。
科技圖書的特點之一是公式和計算多,往往涉及上下標、正斜體、大小寫和各種符號,極易發生排版錯誤。例如,在計算機稿件中,以2為底的冪運算是常見內容,也是“事故多發區”。如210=1024,這么一個簡單的式子,指數10經常排成平排,變成了210=1024。
又如,前兩年網上有一段很火的勵志文,內容大致是,你只要每天比別人多努力1%,一年之后,你的收獲就是別人的38倍。即

曾有科技圖書作者引用了這個例子,但在排版時,把指數365排成了平排。
分子式錯排也常常出現,例如H2SO4錯排成H2SO4,Al2O3錯排成AL2O3等。
上面的錯誤,多看幾眼就能看出來。可是有些公式錯誤就不太容易發現了。筆者在2018年的稿件復審工作中,連續發現了兩本稿件中的麥克斯韋方程組排版錯誤。麥克斯韋方程組有如下特點:基本方程數量多,有4個;表達形式多,有微分形式和積分形式;表述方式多,有微觀表述和宏觀表述。經過以上組合,方程總數可達16個之多。而且每個方程書寫復雜,涉及多種運算符號和字體,如點積符號、叉積符號、哈密頓算子、英文黑斜體和多個希臘字母。其中,叉積符號很容易誤寫(排)為英文字母x,而幾個希臘字母特別容易和英文字母混淆,如ρ和μ等。因此,一旦出錯,錯誤就可能“成批”出現。近幾年,隨著通信技術的蓬勃發展,通信類圖書在科技圖書中的比重也越來越大。而麥克斯韋方程組是這類圖書的重要內容。因此圖書編輯一定要牢記每個方程的正確寫法。
對一些不規范的表達方式,一般是要求統一修改的。例如,臺灣把software譯為軟體,而大陸譯為軟件,如果稿件中的科技術語使用了臺灣的表達方式,需要改為對應的大陸表達方式。有些編輯生搬教條,根本不看上下文,就全稿使用文本編輯軟件中的統一替換功能,這有可能造成正確的內容改錯。例如,我社有一本計算機稿件,在講解面向對象編程技術時,使用了一個動物分類的例子,里面出現了“軟體動物”,結果編輯進行了全文統改,把“軟體動物”變成了“軟件動物”,好在復審人員及時發現。
還有一個問題需要注意:*是多種計算機語言中的乘號,在代碼中頻繁出現。而在數學公式中表示相乘時,要把*改成×或?。一些編輯根據這個要求,看到公式中有*往往不假思索地將其改成×或?。但有一種重要的數學運算——卷積,也使用*,例如,函數f與g的卷積記作f*g,而不能寫成f×g或f?g。如果一味統改,就會出錯。
也許是和計算機語言打交道太頻繁,許多作者在行文時喜歡直接使用計算機語言中的詞匯,似乎不太會說漢語了。例如在一本計算機數據庫稿件中出現了下面的句子:“要刪除key1,直接delete(map1,key1)即可。”乍一看,這句話沒有動詞。其實動詞是有的,那就是delete,這是數據庫語言中的一個關鍵詞。此處應該將“delete(map1,key1)”改為漢語“使用命令delete(map1,key1)”,這就不會造成閱讀障礙了。
只要學過初中幾何,就應該知道內切圓和外接圓。這兩個數學名詞是AutoCAD等工程設計稿件中的高頻詞。但是,近幾年,筆者在審稿時,頻頻發現“內接圓”和“外切圓”這樣的錯誤,而且這些錯誤發生在不止一位作者的稿件中,很令人費解。這顯然是把“接”和“切”弄反了。
科技圖書中有一些發音或寫法特別相似的術語,如友矩陣和酉矩陣、數據包和數據報、連接和鏈接、渦輪和蝸輪。這些術語還可能在一頁當中同時出現。囿于篇幅,本文不解釋這些術語,編輯同人只要知道有這些特別接近的術語即可,在加工或審讀稿件時如果遇到類似問題,可以根據上下文判斷術語使用是否正確。
古語云:差之毫厘,謬以千里。一個數后面有幾個零,小數點后面有幾位,在科技稿件中是個很重要的問題。例如,在一本機械制圖稿件中,有這樣一句話:“剖切索引符號由直徑1000mm(A0、A1、A2幅面)和直徑800mm的圓圈(A3、A4幅面)……共同組成”。看到這里,稍有生活常識的讀者就會問,A4幅面不過20多厘米長,怎么能畫下直徑800mm(也就是80cm)的圓呢?數量級顯然有誤。實際上,索引符號的圓直徑應為8~10mm,不知何故,作者把兩個數值擴大了將近100倍。
這個錯誤還不算嚴重。因為讀者在制圖過程中,遇到這個錯誤肯定是無法繼續的。可是,某出版社的科技圖書,曾經寫錯電壓的數量級,某工廠的讀者在生產過程中卻未能發現,直接使用了錯誤的電壓,致使電機燒毀。好在讀者只是向出版社抱怨了幾句,如果工廠提出索賠,或者燒毀的電機引起火災,出版社不知會付出多大的代價。
有責任心的計算機圖書作者都會事先運行自己稿件中的代碼,確保其正確無誤。但代碼不是漢字,比較抽象,多數排版人員也缺乏相應的知識,在排代碼時,往往只是控制字體字號,不會注意內容,容易造成代碼版式錯誤。這個問題在以前不算嚴重,但近幾年隨著Python圖書的大量上市,越來越突出,需要引起編輯的格外重視。因為Python非常特別:和C/C++,Java等語言不同,它嚴格要求嵌套的代碼必須縮進,即直觀地看,一段較長的Python代碼不可能是左對齊的,一定是鋸齒形排列的。某出版社在處理作者的電子稿時,因為排版軟件問題,把Python代碼排成了全部左對齊,而后續各環節的工作人員都不熟悉Python,沒有發現這種版式錯誤,出書之后才被作者和讀者發現,造成了惡劣影響。
另外,在Linux/UNIX稿件中,豎直的“|”符號(管道符)容易誤排成傾斜的“/”符號,這也需要引起編輯注意。
嚴格地說,在代碼中用漢語拼音作變量名或函數名不算錯誤,但這是程序員的大忌,因為這樣做不利于國際交流。特別是在目前,我國許多軟件公司都承擔了軟件外包工作,直接和外國客戶打交道,如果代碼中出現漢語拼音很可能無法通過客戶驗收。要解決這個問題,首先需要作者提高英文水平,不能只追求程序可以正確運行。其次,編輯也要有這方面的意識,不要認為拼音不算錯就任其泛濫。
科技發展日新月異,科技書必須反映這種變化。不能與時俱進的科技書是毫無價值的。然而,時至今日,一些計算機安全稿件,在講解計算機病毒的章節中,還充斥著“DOS”、“Windows 2000”、“軟盤”等詞匯。讀者如果看到這些將近20年前的內容,會做何感想?還有些物理、化學課本,書后所附的化學元素周期表中,第113、115、117、118號元素還在使用臨時名稱Uut,Uup,Uus,Uuo,實際上它們已經有了正式名稱Nh,Mc,Ts,Og。還要注意的是,在加工稿件時,國標也是個重點檢查對象。例如,許多CAD軟件的版本是每年都升級的,介紹這些軟件的圖書也會做出相應修訂。可是,作者在修訂圖書時,往往流于形式,只滿足于更新一下軟件的截圖,添加一些大同小異的習題,“再版”工作就結束了,可是書中的國標往往已變舊卻不知道更新。遇到國標,建議同行先查閱工標網(http://www.csres.com),確定稿件中的國標是否已廢止,再根據實際情況,查閱相關國標的具體內容。內容過時的問題主要出現在本版高校教材中,但也有些引進的店面書,由于種種原因,拖延多年才出版,上市后內容已陳舊,造成圖書滯銷。
筆者以前審讀過許多數據結構稿件,也看過一些國內作者的著作,發現有一個例子的出現頻率特別高:求一只足球隊的陣型組合數,例子中的球員位置都是很陌生的詞匯,和人們熟悉的“前鋒”“后衛”等不太一樣。筆者一直感到奇怪。直到有一天在一本英文原版的組合數學教科書中看到了一個美式橄欖球隊(也叫美式足球)的例子才恍然大悟:教科書作者像多數美國人一樣,習慣把美式橄欖球稱作football,第一個使用這個例子的中國作(譯)者可能不太熟悉體育運動,將其譯成了足球。后來其他作者奉行“拿來主義”,造成謬種流傳。這種錯誤并不影響學習,但它反映了部分作者不求甚解的寫作態度,也讓嚴肅讀者對整本書的質量產生懷疑。
隨著對外交流的增加,版權輸出成為許多出版社的重點工作之一,圖書封面上添加英文也就成了必選項。封面是一本書的門面,上面的內容一定要認真檢查。可現狀是,大多數編輯和美編的英文水平還不高,難以發現英文錯誤。筆者就見過某出版社的一本教材,在封面上把版次3rd edition寫成了3nd edition,嚴重降低了圖書的品位。
其他錯誤,如錯別字、病句等,是所有稿件的通病,本文不再贅述。
在數字閱讀和碎片化閱讀大行其道的今天,許多讀者仍鐘情紙書,而不是在網上尋找相同或相近的內容,原因之一就是他們認為紙書經過出版社層層把關,錯誤少,質量高。編輯不能辜負讀者的這份信任,要用“如履薄冰”的態度加工和審讀稿件,認真把好質量關。