要是在以前,面对《编辑的权力》这样的题目,我个人作为编辑,也不禁会怀疑,苦笑状,悲叹,编辑哪有什么权力?从初入出版社实习到正式做编辑很长的一段时间,我就从来没认为编辑是个有权力的工种,还曾经自嘲做编辑要“上得了会场,下得了库房;审得了稿件,完得成码洋;拉得了作者,上得去销量;谈得了版权,打得了胜仗;受得了委屈,记得住理想……”同行之间交流,彼此都亲切地自称“苦逼”的编辑。那闪着金光的“权力”二字,离我们不知道有多遥远,也许,要多远有多远。
后来陆陆续续地与一些朋友聊天,我渐渐开始意识到并思考这个问题——编辑的权力问题。一次,与某位作者朋友聊天时,听他不经意吐槽,“你们同事某某,我朋友一本译著在他手里,那个译文本来很好,挺有风格的,他偏偏把好端端的短句,都按外文从句的形式改成那么长的长句子,我好想给他打个电话,探讨一下这个问题,但是,想想容易起误会,算了”;又一次,“你认识某某吗?她做我的一个稿件,我自认为有亮点的地方,都被她给我删了呢”;再一次,“我出过了那么多次书,都没让我改观点,为什么这次,某某编辑非让我改,那有什么可改的?”……他们的话语里透着不满、怨气,最终落脚到无奈。这种气氛密布的时候,我隐隐地有点感觉到妄行的编辑权力了。权力可能就是这样,安安静静的时候,不会为人所觉察得到,稍有肆意,便暴露无遗了。
还有一次我亲身经历的事情。由于出版节奏的原因,某个稿件时间非常的急,社里协调同事帮我审稿,最后我来统稿,统稿时,发现一个多次重复改动的词语,我有点警醒,就查了一下,发现该词原来是新法规定的一个新术语(电子数据证据),不是错误,被同事好意地改成了一个非术语(电子证据)的常规表达了。于是,我不得不把涉及这种改动的地方一个个地恢复过来,一边画恢复的三角符号,一边心里悄悄地想,这可万万不能给作者看到。
经过种种类似情景之后,我暗暗想,原来编辑的笔起笔落,都是权力啊。再面对稿件的时候,心里变得比较忐忑,常常嘱咐自己可千万要谨慎,可千万不要以自己想当然的想法去修改,招来作者背后的鄙视,以至无奈地跟别人抱怨。总有很多人问我,作为编辑,你们怎样来发现作者稿件的问题?这实际上是个比较礼貌的问法,翻译成直接的表达就是,你们做编辑的,比作者都高明吗?不会比作者都高明吧,那怎么能审得了作者拟出版的各种稿件?这是一个特别好的问题,的确,编辑并不一定都比作者高明,但是经过编辑训练,会对问题很敏感,敏锐发现问题,并进行查证。从这个角度上说,编辑本身也许并不在于知识储备上多么深厚,而是不断地对前沿问题进行关注、学习,善于存疑,并利用查询检索手段进行确认,这些方面的能力更强一些。
于是,审稿的时候,对于那种确定无疑的错误,就直接改正;如果有怀疑的地方,自己必须先查资料进行核对,有靠谱资料佐证的情况,进行改正;对于那些觉得存在问题,又找不到相关依据,无法直接修改的地方,就先存疑,说明原因,与作者沟通进行解决。
稿件中,在出版纪律方面,在作者表达习惯方面,在语言、观点是非对错方面,等等,经常是改与不改,删与不删的高发地带,在改与不改、删与不删之处,编辑的权力毕现。如何提高编辑的审稿能力,妥帖地行使编辑的权力,遵守出版纪律,也尊重作者的表达,尽可能地给作者的稿件进行补强,修正其谬误,增添其光彩,让作者评价为“那是一个有水平的编辑”,我觉得,这既是一个编辑的职业追求,也是社会分工中编辑存在的意义吧。
网友评论
第二种情况会造成简书服务器CPU用量增大吗?
但这个在HTML里不存在。。。
但,这倒不是说我们对此就素手无策,如果抛弃后期维护的成本的话,这事是可以做到的,下面是两个思路:
根据文本长度和页面宽度,计算出每行最多多少字才能保证不换行(这个可以人为规定,也可以通过DOM来获得,后者比较消耗浏览器计算力)。
然后,以行为单位生成DIV,每个DIV就是一行文字内容。
第三部,根据每行DIV的实际宽度(boundingClientRect的width,或者DIV的offsetWidth,前者比较好,但低版本IE上不支持),使用transform:scaleX(...)进行拉升,于是两边对齐了。
这个的缺点,很显然,就是文字会变形。。。
第二个方案比较完美,就是将在第一个方案每行一个DIV的基础上,将每个字符都转化为Span,然后设置Span之间的Margin,这个都可以通过纯计算获得。
这样的效果比较完美。
缺点是:浪费了大量浏览器计算力。。。。。。
#无聊开脑洞成就再度达成。。。。。。