On Mon, Jul 19, 2004 at 02:58:57PM +0000, Jean-Luc Coulon (f5ibh) wrote: > Mais que le d�lai soit > d'un mois de 3 mois ou d'un an, mon exp�rience montre que le r�sultat > est toujours le m�me : on n'a la mati�re qu'au dernier moment.
Alors l�, nous sommes absolument d'accord :) Au dernier moment et avec un volume qui n'�tait pas celui attendu/estim� (trop court ou trop important). Mais ce sont l� les joies de la publication :) > Je ne comprends pas trop la question. Est-ce qu'il s'agit de revue de > radio dont vous parlez ? oui. > M�gahertz : de tr�s bonne tenue. Tr�s petite bo�te. Cette publication a > �t� victime de nombreux remous de par le pass�. Elle fonctionne > aujourd'hui sans probl�me particulier si ce n'est qu'elle repose sur > les �paules d'une seule personne. Celle-ci correpond sans doute le plus � Linux Mag. Et si je ne me trompe pas il s'agit d'un 72 pages + 4 de couverture ce qui n'est pas loin de Linux Mag. Cependant, la bonne tenu au num�ro 255 peut, sans doute, �tre mise en balance avec nos 96 pages (128 fut un temps) et notre dernier num�ro qui est le 63. Vu la description que vous faite, la taille de l'�diteur de M�gahertz doit sans doute correspondra avec celle de Diamond Edition. > Pour en revenir � LVM, je comprends bien toutes les raisons. Mais > expliquer ne suffit pas. Il est � mon avis *n�cessaire* de viser � > am�liorer la qualit�. > - Lorsqu'un exemplaire sort avec des articles en vert clair sur vert > fonc� avec des caract�res d'une taille ridicule, on s'en apre�oit (je > vous l'ai �crit d'ailleurs) et on corrige le tir... On ne fait pas la > m�me chose 6 mois plus tard avec du beige � la place du vert. C'est sans doute vrai mais pour �tre tout � fait clair nous ne pensions pas obtenir un r�sultat aussi peu lisible avant l'impression. L'erreur � �t� r�p�t�e malheureusement, mais n'oublions pas qu'il s'agit de l'adaptation d'une nouvelle maquette (num�ro 60) et qu'un certain nombre de coquilles infographiques ont �t� commise. > - Une relecture rapide permet de corriger toutes les grosses fautes, > celles qui se jette � vos yeux : les participes pass�s � la place des > infinitif et vice-versa, l'accord de ces participes pass�s. Si en un > quart d'heure, j'en rel�ve un par minute, je me demande le type de > correction que cherchent � apporter ceux qui en font la relecture. > (mon exp�rience � ce sujet : celui qui relit dans le but de corriger > les fautes de fran�ais ne doit s'occuper *que* de cela et pas de > corriger le *contenu* de l'article. Le contenu �tant de la > responsabilit� de l'auteur. Si on s'attache � *lire la revue*, on va > fatalement ne voir que le contenu et pas la forme. Ce n'est pas le but > des relectures). Certe, d'un point de vue th�orique c'est exact. Mais dans le domaine qui nous occupe il est bien n�cessaire de comprendre l'article pour bien relire. En effet, pour les articles de programmation par exemple, seul un italique ou une police distingue une variable d'un mot courant. Sans doute allez-vous le dire qu'une variable nomm�e comme un mot courant est une mauvaise id�e, mais les d�veloppeur ont encore, du moins dans Linux Mag, la libert� de d�velopper comme ils le souhaitent. La t�che des personnes � la relecture pr� et post mise en page n'est pas ais�e tant en raison du niveau technique, que des moeurs et habitudes des auteurs. Je ne mentionnerai pas de noms ici, mais certains articles nous arrive presque sans fautes et autre avec une densit� de fautes et de typo au centim�tre carr� qui fait froid dans le dos. Il faut comprendre donc qu'en passant d'un article � l'autre, les relectrices (et teurs) doivent s'adapter. Devrais-je pour autant �carter ces auteurs ? Certainement pas, d'autant que souvent, il s'agit de ceux-l� m�mes qui maitrisent le mieux des domaines aussi int�ressants que pointus (mais ce n'est pas une r�gle loin de l�). Pour conclure donc ce fil (qui finit plut�t bien je pense mais qui n'a rien � faire ici), je vous assure que la pr�sence d'erreur, de typo, et de fautes dans le magazine n'est en rien le r�sultat d'un certain laxisme. Le mag est le fruits d'efforts aussi bien de la part des auteurs que de l'infographie et surtout de la relecture. ++ -- Denis Bodor "sudo kill -KILL -1 . . . Le Kernel reconna�tra les siens" Error is human, but to really foul things up requires a computer http://www.lefinnois.net Irc : Lefinnois
