OK, am definitivat versiunea 1.2 a scriptului de corectură pentru MS Word 2011, cu următoarele noi funcții și îmbunătățiri:

  •  Parte de corectură pas-cu-pas inteligentă, cu 15 tipuri de greșeli care nu se pot corecta automat (vedeți care sunt acestea în tabelul din fișierul “Instrucțiuni”);

  •  Câteva corecturi automate noi (vedeți tabelul din fișierul “Instrucțiuni”);

  •  Pentru siguranța documentului inițial, scriptul nu mai rulează pe un document nesalvat;

  •  Pe durata rulării scriptului, funcția ‘Track Changes’ va fi dezactivată (în MS Word, funcția respectivă nu poate ține pasul cu corecturile automate, și dispar litere din text);

  •  La final, documentul e salvat cu o altă denumire, apoi e comparat cu cel inițial, cu posibilitatea de acceptare sau respingere individuală sau totală a corecturilor făcute (din ribbonul/panoul ‘Review’, secțiunile ‘Tracking’ și ‘Changes’).

Notă despre compatiblitate: scriptul rulează și pe Snow Leopard (minim 10.6.4), dar recomand rularea pe versiuni de Mac OS X de la 10.7 în sus.

Mulțumesc lui Vladlitteram, Altero și, bineînțeles, d-lui prof. Sorin Paliga pentru sugestii, testare și consultanță. Și pentru răbdare, că a durat mai mult decât am anticipat.

Scriptul e ușor de folosit și e destul de clar și logic (cred), dar totuși recomand o citire pralabilă a fișierului “Instrucțiuni”.
Dacă sunt nelămuriri, sugestii sau probleme întâmpinate, scrieți aici sau la adresa de e-mail din caseta de dialog “Despre script”.

Mulțumim!

Mulțumesc!!!!!!!!

Mulțumim! Aveam mare nevoie de așa ceva. Abia aștept să-l testez!

Am o problemă. Nu-l pot instala. După “Selectare destinație” nu merge mai departe.

Probabil nu ai instalată ultima versiune de Word (14.4.x parcă)? Sau vezi de versiunea de sistem, să fie minim 10.6.4, deci Snow Leopard.

Instalat, corectat un document, făcut modificări în document, încercat să-l corectez iar și s-a blocat wordu’.
OS X 10.9.4, word 14.4.4 (140807).
@Artistul

Dacă scriptul nu se instalează, motivul poate fi unul din următoarele trei:
( 1 ) Rulați o versiune de sistem de operare mai veche decât Mac OS X 10.6.4;
( 2 ) La instalarea suitei Microsoft Office 2011 nu ați instalat și pachetul Visual Basic for Applications (VBA) inclus, sau
( 3 ) Nu aveți instalată suita Microsoft Office 2011.

@ nvmarian:

Mulțumesc, am uitat să amintesc aici lui Artist de treaba cu Visual Basic. Practic trebuie rerulat installeru’ de Office 2011, și bifat Visual Basic for Applications.

Cu blocarea:

Da, așa e: dacă textul e lung și mai are și multe “buline” cu indicațiile funcției “Track changes” (de la corectura precedentă), nu e OK să rulezi scriptu’ pe așa ceva – Wordu’ nu face față la atâta “informație” suplimentară, și se blochează, trebuind să-i dai Force Quit.

Recomand acceptarea/respingerea totală sau parțială a corecturilor efectuate (totală se face de la meniul “Accept All Changes in Document” al butonului “Accept” din panoul Review), deci toate corecturile să fie “permanentizate” sau respinse, apoi după salvarea documentului, n-ar mai trebui să se blocheze la o nouă rulare a script-ului. Tocmai am testat pe un text lung de 120 de pagini, și cu corecturile neacceptate se blochează la fiecare încercare, și cu ele acceptate, merge.

Soluție pentru versiunea 1.2.1: scriptu’ să verifice “situația” înainte să pornească la căutarea greșelilor, și dacă e cazu’, să ceară utilizatorului să facă treaba descrisă mai sus. Actualmente caută greșelile, apoi când începe să facă corecturile, dezactivează Trackingu’. Pe texte mai scurte nu se blochează, pe texte lungi da.

O altă scăpare relativ minoră care acuma am observat-o e că nu menține nivelul minim de zoom la minim 150% când arată potențiale greșeli din notele de subsol, din coloncifru etc. (Zoom-ul de minim 150% e menit să ajute utilizatorul să vadă bine textul atunci când decide asupra corecturilor făcute pas-cu-pas). Deci probabil o rezolv și pe asta în versiunea 1.2.1.

Mai aștept alte probleme, dacă sunt. 

Documentul meu are aproape 200 de pagini și este plin de dude.
Am reușit să-l corectez iar după acceptarea totală a modificărilor.
După l-am mai corectat de câteva ori. Nu a reușit scriptul să identifice toate greșelile din prima rulare deși selectam toate opțiunile.
Dacă în text există “cuvânt”“virgul㔓cuvânt”“virgul㔓spațiu” la corectarea cu confirmare pentru “spațiu” după “virgulă” atunci dublează ultimul spațiu.
150% pentru zoomul notelor de subsol este perfect. Eu m-am descurcat și așa. 

Mulțumesc!

Mda… asta cu “cuvânt,cuvânt, ” e bug. Revin cu un 1.2.1 după week-end.

Bogdan a explicat mai pe larg, eu nu înțeleg cauza motivului rezultatului care este (sub SL în QXp 9.x):
Trec cu scriptul prin text, salvez corectura și apoi,
– dacă aduc textul din .doc(x) prin copy-paste, hyphen - dispare și e înlocuit cu spațiu.
– dacă-l aduc prin import (cmd-E), NBH rămîne și QXp îmi arată că e tot din fonta folosită (nu din alta).

Pun problema aici, că pe mine nu mă duce mintea deși mi s-a explicat cum devine de aproximativ patrusute de ori . Dar ce e de făcut (nu cu mine, cu NBH)?

Mulțam! Altminteri scriptul lui Bogdan este genialissim și în practică eroarea asta se ocolește ușor prin funcția de import (doar atenție: de debifat în ferestra de confirmare a importului preluarea stilurilor din Word, care trîntește altminteri o duzină de stiluri folosite-nefolosite de-a valma)

Hai că încerc să rezum situația și aici, ca să înțeleagă lumea despre ce vorbim:

• În limba română regula e ca întotdeauna să se folosească liniuța de unire (cratima nonsecabilă, non-breaking hyphen, de la adresa Unicode U+2011) în cazul cuvintelor compuse gen “într-un”, “ne-am”, “le-ați”, “nu-mă-uita”, “e-mail” etc., pentru că asemenea cuvinte nu se despart pe rândul următor tocmai unde au liniuță;

• Din nefericire pentru noi, românii, majoritatea fonturilor respectabile (chiar și dintre cele incluse de Adobe cu programele lor de grafică, de Apple cu sistemul de operare sau de Microsoft cu suita Office) nu au NIMIC desenat la adresa U+2011, deci nu conțin caracterul Non-Breaking Hyphen;

• Dar, din moment ce Non-Breaking Hyphen e identic ca formă (ca “desen” să zic așa) cu cratima aia “normală”, uzuală, ce se introduce de la tastatură (Hyphen-Minus, U+002D), majoritatea procesoarelor de text (Word, Nisus, OpenOffice…) afișează un HM în loc de NBH-ul lipsă, și îi aplică acestei cratime normale atributele de “unire” necesare, pentru ca respectivul cuvânt să nu se despartă unde are liniuța;

• Bineînțeles, fiecare din aceste programe are formatul lui nativ de document, cu propriul mod de “descriere” în cod (XML sau ce-o fi) a acestei cratime normale cu atribuții speciale;

• Problema apare când în anumite programe de machetare se aduc texte ce conțin așa ceva – InDesign-ul (și nici Pages, din câte am înțeles) nu o “decodifică” așa cum trebuie, și te trezești fără liniuțe, deci nici măcar spații goale în loc nu rămân. Quark-ul nu are probleme la import de fișiere .docx (din câte știu, chiar MS le-a scris modulul de import), dar la copiere din Word și inserare cu Cmd-V în QXP, textul nu mai trece prin modulul de import scris de MS pentru QXP, ci prin clipboardu’ sistemului, care nu știe de-alea, și rămâi cu spațiu gol (sau poate cu caracterul .notdef – un dreptunghi gol sau tăiat cu X) în loc de cratimă.

Din moment ce nu pot obliga utilizatorul final să aducă textul prin import și nu prin copiere, altă soluție nu am decât o explicație mai bună, mai clară, mai explicită despre diferența dintre import și copiere, pentru ca omu’ să știe cum procedează ulterior cu textul.

* Explicația curentă (v.1.2.10) afișată de script e următoarea:

“În limba română toate cuvintele compuse precum „într‑una”, „nu‑i”, „du‑te” nu se despart la sfârșit de rând. „Liniuța de unire” (cratima nosecabilă, Non‑Breaking Hyphen, NBH) este semnul care are și funcția de a împiedica trecerea pe rândul următor a părților de cuvânt care îi urmează.
 
„Liniuța de unire” (NBH) și „liniuța de despărțire” (Hyphen-Minus, HM), deși vizual identice, au adrese diferite în tabelul Unicode (U+2011, respectiv U+002D). În cazul în care, în fontul utilizat, NBH lipsește de la adresa U+2011, fiecare program DTP are metoda sa proprie de a afișa o cratimă simplă (HM) în locul liniuței de unire (NBH).

Din păcate, acest NBH codificat special dispare la importul fișierelor .docx în Adobe InDesign sau în Apple Pages. Dacă textul va ajunge într-unul din aceste două programe, soluția alternativă oferită de scriptul de corectură e înlocuirea HM cu un NBH de la o altă fontă care îl conține.

Pentru celelalte programe de machetare, alegeți substituirea cu liniuța de unire (NBH) din Word.”

[  InDesign/Pages ]  [  QuarkXPress/OpenOffice etc.  ]

Cum altcumva să fie? Ziceți

E foarte clar ce spui, NBH e o mare dandana.
M-aș apuca să corectez eu toate fonturile de MS și sistem, dacă nu mi-ar fi frică de proprietari. O scrisorică la ei n-ar fi bună?

Da, deci din punctul de vedere al tuturor procesoarelor de text și al programelor de machetare cunoscute și “consacrate”, problema cu NBH e rezolvată “intern” pe partea de suplinire a NBH-ului lipsă cu un HM “cu puteri speciale”, dacă introduci NBH cu scurtătura aferentă. Deci “în afacerile interne” totul e OK – bravo tuturor. (Da, și InDesign are mecanism intern similar pentru o asemenea suplinire).

La afacerile externe, deci la partea de import e buba – InDesign și Pages dau chix cu importul de .dochix, Quark și OpenOffice le importă bine, dar la copiere din Word și inserare în alt program (deci trecere prin clipboardu’ sistemului) toate au problemă din cauza modului de copiere în clipboard al sistemului, care ia numai ce e “la suprafață”, ca să zic așa, deci numai HM simplu, fără funcția de unire atașată acestuia de Word.

Părerea mea: Scrisorică ar merge dacă s-ar trimite pentru partea de import la Adobe, să dreagă InDesign-ul, și la Apple, pentru Pages. (Apropo, problema cu ID e semnalată la ei pe forum de multă vreme, și nu știu să se fi rezolvat încă).

Dar cu copierea în clipboard… nu știu ce să zic… ar însemna ca Apple să dea puteri speciale de convertor de .docx-uri mecanismului clipboard. O fi realizabilă treaba? Nu știu.

Deci aici și acum tot la o explicație mai bună ajung: Să adaug în caseta aia de dialog și o recomandare ca ulterior textul să fie adus în alt program cu funcția de import a acestuia, nu de copiere și inserare? Parcă asta ar fi cel mai OK, ca să împăcăm și capra, și varza.

* Chiar dacă creatorii programelor FontLab și DLT OTMaster se laudă că pot decompila, modifica, apoi recompila la loc fonturile fără pierderi de features, treaba cu modificarea fonturilor e un pic nerecomandată de “tipofili”, și pe bună dreptate – cei care sunt în măsură să facă modificări fără probleme cu pierderi de kerning , ligaturi și alte funcții sunt numai creatorii fonturilor, care au fișierul nativ după care s-a generat fontul.

La textele NEcorectate cu scriptul bogdanez funcționează copiere-lipire. Cred că soluția e într-adevăr recomandarea strictă ca textele corectate cu scriptul să fie aduse în machetă numai prin funcția de import a programelor (cmd-e în QXp). Obiceiul copy-paste e greu de combătut, cum știm

Despre © la garniturile de literă nu s-a mai vorbit de mult pe-aici Cf. legii © (SUA) și a Drepturileor de autor (UE) din cîte știu modificarea unor „opere” străine presupune acordul expres al deținătorului de drepturi/ autorului și nu dau calitatea de coautor celui care le face. Dacă programul cu care le deschizi mai și distruge setările tipografice, se mai adaugă și delict (chiar și la cele freeware!) – la defectul tehnic. Pe vremuri, cînd jurisprudența deci și contractele erau mai cețoase în această privință, era un atelier în DE care româniza, ploniza etc. fonte PS –  semilegal și pe bani destul de mulți. Îmi închipui că situația obținerii-acordării unei eventuale permisiuni e juridic atît de complexă, încît ar fi de mii de ori mai simplu să repari comprtamentul sistemului decît să obții permisiunea și apoi să unifici „sustenabil” producția și actualizarea garniturilor… Dar cine să stea să-ți veriice ție garniturile?