EditDoc 0.1.31: layout por trechos e o padrao em documento com tabela

Digitar antes de tabelas sem refazer as tabelas de baixo. No documento com tabelas, o layout do
Qt (QTextDocumentLayout) refazia TODAS as tabelas depois do ponto editado a cada tecla, mesmo
quando nada se movia (docs/SPIKES.md, 0.1.14 e 0.1.15): no plano de teste com 16 tabelas, a tecla
sozinha levava 12 a 17 ms. Desde esta versão o corpo do documento com tabela no primeiro nível é
paginado por trechos (editdoc/interface/trechos.py, LayoutPorTrechos): o documento continua um
só (edição, cursor, desfazer, localizar, gravação), e o layout dele junta um QTextDocument por
trecho (do bloco depois de uma tabela até a tabela seguinte), cada um com o layout do próprio Qt e
posto na mesma altura da página por um espaçador. A tecla refaz só o trecho dela; o de baixo, só
se o fim do trecho mudou de lugar. Documento sem tabela fica no layout do Qt, como antes.
EDITDOC_TRECHOS=0 no ambiente volta ao layout do Qt em todo documento (o escape está no README).

Gate (p95 em ms da tecla com a pintura, núcleos P fixos, base e versão intercaladas, mediana de 3
rodadas; entre parênteses, a tecla):

Ponto	0.1.30	0.1.31
documento simples	6,0 (1,8)	6,1 (1,9)
plano, 1/3	21,8 (16,4)	10,1 (4,6)
plano, célula	18,1 (11,8)	8,4 (3,0)
plano, item de lista	18,7 (13,6)	7,9 (2,5)
plano com Controlar alterações	22,8 (16,8)	10,2 (4,5)
manual (capa, sumário, corpo)	8,9 / 9,8 / 7,8	8,6 / 9,6 / 7,4
capa cheia, antes das âncoras	14,4	14,3
2000 revisões, controle ligado	6,8	6,6

No plano real (16 tabelas) na janela de 1400 × 950: 19 a 27 ms → 11 a 15 ms. Trocar o modo das
revisões num documento de 2000 revisões com tabelas: 1,25 s → 0,6 a 0,9 s. Abrir o plano: 2,2 s →
2,3 s.

Conferido: as linhas de todos os blocos (inclusive nas células) nas mesmas posições do layout do
Qt, ao abrir, digitando antes das tabelas, numa célula, num item, com Controlar alterações, Enter,
Backspace, desfazer, tabela nova e tabela apagada (tests/teste_trechos.py); a pintura de cada
folha como no papel (PDF e impressão), com seleção atravessando trechos, em colunas e em seções de
papel diferente, comparada pixel a pixel com a do layout do Qt; oráculo de páginas dos 16 .docx de
referência e regressão c14n iguais com e sem o layout novo. A suíte roda uma segunda passada com
EDITDOC_TRECHOS=0 nas suítes que abrem documento com tabela (tests/rodar_todos.py).

Limites: cada trecho começa até 0,6 twip (0,03 pt) fora do lugar exato, porque a altura do
espaçador anda em passos inteiros: na tela, uma letra ou a borda da seleção pode cair no pixel
vizinho (até 0,8% dos pixels de uma folha). A linha de tabela que não deve partir entre páginas
(w:cantSplit) continua partindo, como antes. Digitar DENTRO de uma tabela muito grande continua
refazendo a tabela inteira (só ela).

EditDoc 0.1.30: gate do plano contra o Qt puro, a prova de nucleo

Gate de desempenho do plano à prova de núcleo. Uma medição apontou que a 0.1.29 (colunas) dobrou
a digitação no documento com muitas tabelas (tecla 17 → 35 ms, pintura 5 → 12 ms). Não dobrou: a
0.1.28 e a 0.1.29 medidas intercaladas, no mesmo núcleo, dão o mesmo tempo (tecla 16,6 ms nas
duas, pintura 5,0), e o perfil de 80 teclas é igual (1,94 s nas duas, as mesmas chamadas de
pintura). O dobro vinha do Windows: o processador híbrido (núcleos P e E) mandou o processo de
medida para um núcleo E, que leva o dobro em tudo; a medida da 0.1.28 tinha sido feita na véspera,
num núcleo P. Fixando o núcleo, 0.1.28 e 0.1.29 dão 17 ms nos P e 35 ms nos E.

Novo ponto em tests/teste_desempenho.py (testar_plano_sobre_o_qt): a tecla e a pintura do
plano medidas contra o insertText do Qt num clone do mesmo documento, tecla a tecla intercaladas.
A razão não muda com a carga nem com o núcleo (tecla 1,4 a 1,8x o Qt, pintura 0,4 a 0,6x, nos P e
nos E), e reprova o EditDoc fazendo o trabalho do Qt em dobro (2,8x) ou perdendo o cache de tiles
a cada tecla (1,6x a pintura). O programa não muda.

Texto em colunas. A seção com colunas iguais (w:cols com num, space e equalWidth) que
começa e termina em página nova aparece em colunas na tela, no PDF e na impressão: a página do Qt
passa a ter a largura da coluna e a folha junta as colunas lado a lado (GrupoDeColunas em
modelo/folhas.MapaFolhas). Cursor, clique, seleção, setas, PageUp/PageDown, campos PAGE e
NUMPAGES (contam folhas), barra de status e notas (no pé da coluna da referência) seguem as
colunas. A linha entre colunas (w:sep) e a quebra de coluna no começo ou no fim do parágrafo
entram; o arquivo salvo volta com as mesmas w:br type="column".

Fora desta versão (aviso, arquivo intacto): seção contínua com colunas, colunas desiguais, quebra
de coluna no meio do parágrafo, equilíbrio da última folha. A régua mostra a folha, não a coluna.

Medido (docs/SPIKES.md, "Colunas iguais: passos 2 e 3"): tests/teste_colunas.py com 73
verificações (3537 no total, 0 falhas); oráculo dos 14 .docx de referência e regressão c14n
iguais à 0.1.28 (nenhum deles tem colunas); gate de desempenho sem piora.

EditDoc 0.1.29: texto em colunas na tela, no PDF e na impressao

Texto em colunas. A seção com colunas iguais (w:cols com num, space e equalWidth) que
começa e termina em página nova aparece em colunas na tela, no PDF e na impressão: a página do Qt
passa a ter a largura da coluna e a folha junta as colunas lado a lado (GrupoDeColunas em
modelo/folhas.MapaFolhas). Cursor, clique, seleção, setas, PageUp/PageDown, campos PAGE e
NUMPAGES (contam folhas), barra de status e notas (no pé da coluna da referência) seguem as
colunas. A linha entre colunas (w:sep) e a quebra de coluna no começo ou no fim do parágrafo
entram; o arquivo salvo volta com as mesmas w:br type="column".

Fora desta versão (aviso, arquivo intacto): seção contínua com colunas, colunas desiguais, quebra
de coluna no meio do parágrafo, equilíbrio da última folha. A régua mostra a folha, não a coluna.

Medido (docs/SPIKES.md, "Colunas iguais: passos 2 e 3"): tests/teste_colunas.py com 73
verificações (3537 no total, 0 falhas); oráculo dos 14 .docx de referência e regressão c14n
iguais à 0.1.28 (nenhum deles tem colunas); gate de desempenho sem piora.

EditDoc 0.1.28: linha da Aptos pelas metricas tipograficas

Altura da linha nas fontes com métricas tipográficas (Aptos). A fonte que marca USE_TYPO_METRICS
na tabela OS/2 (a Aptos, padrão do Office atual) tem a linha pelas métricas tipográficas no Word e
no Qt; até a 0.1.27 o EditDoc calculava a linha do Word pelas métricas do Windows (win), 5,3%
mais alta, e esticava cada linha de Aptos (com espaçamento simples ou múltiplo) fora das tabelas.
As páginas com Aptos levavam menos texto que no Word. A correção só vale com a fonte instalada; o
arquivo salvo não muda.

Medido (docs/SPIKES.md, "0.1.28: a linha da Aptos"; oráculo lastRenderedPageBreak dos 14 .docx
de Downloads, Windows, com a Aptos instalada):

• doc_14: 14 páginas, acerto das quebras de 2/2 para 4/4 (Word: 14 páginas, 13 marcas).
• doc_13: 2 páginas, de 1/0 para 1/1 (a quebra cai na linha do Word).
• Os outros 12 ficam iguais à 0.1.27, quebra por quebra (Aptos também aparece no doc_03 a 05, sem
  marcas do Word: páginas iguais).
• Regressão abrir-salvar-reabrir-salvar: c14n igual à 0.1.27 nos 14; salvo1 == salvo2 em todos.
• Suíte: verificações novas em teste_paginacao_word (tabela OS/2 gerada no teste: com o bit, sem o
  bit, OS/2 versão 3, typoLineGap, métrica zerada), com contraprova (código da 0.1.27: 2 falhas).

EditDoc 0.1.27: recuo esquerdo negativo e rodape com tabela na tela

Recuo esquerdo negativo e rodapé com tabela, como no Word. Até a 0.1.26 o parágrafo (ou a tabela)
com recuo esquerdo negativo, que entra na margem, aparecia na margem e com a linha da largura do
corpo: o texto justificado quebrava em mais linhas que no Word e cada página levava menos texto.
Agora ele começa onde o Word o põe, com a largura de linha do Word, na tela, no PDF e na impressão;
o clique, o cursor, a seleção, a régua, os objetos flutuantes, as notas e o cabeçalho e rodapé
ficam no lugar. E o rodapé (ou cabeçalho) com uma tabela seguida de parágrafo vazio tinha uma linha
a menos que no Word (o Qt esconde o vazio junto da tabela): o corpo da página ficava mais alto.

As duas correções entram juntas: só a do rodapé piorava o documento medido (26 para 27 páginas),
porque o recuo ignorado compensava o rodapé curto. O arquivo salvo não muda.

Medido (docs/SPIKES.md, "0.1.27"; oráculo lastRenderedPageBreak dos 14 .docx de Downloads,
Windows):

• doc_12: 26 páginas, acerto das quebras de 1/1 para 2/2 (as duas primeiras quebras no parágrafo e
  na linha do Word; Word: 24 páginas). Os outros 13 ficam iguais, quebra por quebra.
• A margem da tabela depois do parágrafo vazio entre tabelas (entrelinha sem a compensação, 10,9
  twips) foi corrigida e medida: não muda nenhuma quebra; não entrou.
• Regressão abrir-salvar-reabrir-salvar: c14n igual à 0.1.26 nos 14; salvo1 == salvo2 em todos.
• Desempenho (p95 da digitação, rodadas intercaladas): sem piora consistente (a direção inverte em
  todos os documentos).
• Suíte: 3459 verificações ok, 0 falhas; 27 novas em teste_paginacao_word (posição x e largura
  da linha com recuo negativo, tabela, caret, clique, régua, gravação; altura do rodapé com tabela e
  vazio), com contraprova (deslocamento desligado; sem o vazio escondido).

EditDoc 0.1.26: altura da linha de tabela (w:trHeight) na tela

Altura da linha de tabela (w:trHeight) na tela, no PDF e na impressão. Até a 0.1.25 a altura que o
arquivo pede para a linha era guardada, mas a tela mostrava só a altura do texto: uma linha de
cabeçalho com "pelo menos 0,8 cm" aparecia com a altura de uma linha de texto. Agora a linha "pelo
menos" (e a "exatamente", quando o texto cabe) tem a altura do arquivo, com o texto no alto, no meio
ou embaixo, como o alinhamento vertical da célula pede; a "automática" continua com a altura do texto.

O arquivo salvo não muda nos documentos medidos. Uma correção no salvar: a linha com altura
"automática" (hRule="auto") era gravada como "pelo menos" (atLeast); agora volta como veio.

Medido (docs/SPIKES.md, "0.1.26"; oráculo lastRenderedPageBreak dos 14 .docx de Downloads,
Windows):

• Os 14 ficam iguais à 0.1.25 em páginas e em acerto das quebras (doc_12: 26 páginas, 1/1). A altura
  das linhas não era a causa da primeira quebra do doc_12: com ela, o parágrafo da divisa ainda cabe
  na página 1 (faltam 98 twips).
• Espaço antes do primeiro e depois do último parágrafo da célula: medido e não adotado (o doc_14
  piora de 3/3 para 2/2).
• Viúva de três linhas ou mais (descer uma linha): o protótipo resolveu 5 dos 8 casos dos 14
  arquivos, mas não mudou nenhuma quebra do oráculo; não entrou.
• Regressão abrir-salvar-reabrir-salvar: c14n igual à 0.1.25 nos 14; salvo1 == salvo2 em todos.
• Desempenho (p95 da digitação, 3 rodadas intercaladas): sem piora consistente (-1,31 a +1,02 ms). A
  ressalva da 0.1.25 (documento simples +0,4 a +1 ms) era ruído: o documento simples não tem tabela,
  e a 0.1.24 contra a 0.1.25 deu -0,09 a +1,42 ms sem direção.
• Suíte: 3432 verificações ok, 0 falhas; 16 novas em teste_paginacao_word (testar_altura_da_linha),
  com contraprova (sem a altura na tela, 7 falham).

EditDoc 0.1.25: margem da celula (w:tcMar) na tela

Fidelidade de paginação em tabelas: a margem interna de cada célula (w:tcMar) passa a valer na
tela. Antes só valia a margem da tabela (w:tblCellMar), e a célula que traz a sua própria
(topo, base, esquerda, direita) ficava com a margem errada: a tabela ficava mais curta que a do
Word, e a quebra de página caía depois do ponto onde o Word a põe. Nenhuma mudança no arquivo
salvo: o w:tcMar continua nos extras da célula e volta como veio.

Medido (docs/SPIKES.md, "0.1.25"; oráculo lastRenderedPageBreak sobre os 14 .docx de Downloads,
Windows):

• Um arquivo (doc_14) passa de 13 para 14 páginas, igual às 14 do Word; o acerto das quebras sobe de
  1/1 para 3/3 (mesmo parágrafo / mesma linha). Os outros 13 arquivos ficam iguais, em páginas e em acerto.
• Regressão abrir-salvar-reabrir-salvar: c14n igual à 0.1.24 nos 14.
• Suíte: 6 verificações novas em teste_paginacao_word (margem de célula, com contraprova: sem a
  correção, 3 falham).

Não entrou (diagnosticado, fica para a próxima versão): altura mínima de linha (w:trHeight), que a
tela ignora; espaço antes do primeiro e depois do último parágrafo da célula, que o Qt não aplica;
e a viúva de três linhas ou mais.

EditDoc 0.1.24: scripts de spike sem caminho de usuario

Higiene do repositório: os scripts de medição em spikes/ apontavam para uma pasta de
rascunho com o nome de usuário do Windows no caminho. Agora usam a pasta temporária do
sistema (tempfile.gettempdir()). Nenhuma mudança no programa.

EditDoc 0.1.23: PySide6 6.12

Atualização de dependência: PySide6 (Essentials) de 6.11.2 para 6.12.0, fixada em requirements.txt.
Sem mudança de código. Nada muda no que o usuário vê, no arquivo salvo nem nas páginas.

Medido (docs/SPIKES.md, "0.1.23"):

• Suíte completa: 3411 verificações ok, 0 falhas, igual à 0.1.22.
• Build com 6.12.0: BUILD OK, autoverificação "EditDoc 0.1.23", fumaça de janela e ZIP ok.
• Páginas dos 14 .docx de Downloads (oráculo lastRenderedPageBreak): iguais à 0.1.22 em todos, com o mesmo
  acerto das quebras. O SIM continua em 13 páginas (o Word dá 14, pela fonte Aptos ausente nesta máquina).
• Regressão abrir-salvar-reabrir-salvar nos 14: c14n igual à 0.1.22 e mesmas páginas.
• Desempenho (p95 da digitação, 3 rodadas intercaladas): diferença de -0,52 a +0,42 ms, dentro do ruído,
  abaixo do limite de 1,5 ms.

Nenhuma armadilha nova: nada quebrou com a 6.12. O procedimento para testar outra versão do Qt está em CLAUDE.md.

EditDoc 0.1.22: quebra de pagina solta antes de secao

Correção da página em branco antes da quebra de seção. Um parágrafo que só tem a quebra de página
(w:br type="page") seguido do parágrafo com o w:sectPr (quebra de seção "próxima página") gerava
duas quebras seguidas no Qt: o parágrafo da quebra começava uma página e a seção seguinte começava
na outra. O Word deixa o parágrafo da quebra e o da seção na página de cima, e a seção seguinte na
página de baixo. No documento de referência (SIM, 15 páginas na 0.1.20, com a Aptos ausente nesta
máquina) isso era a página em branco entre a capa e o sumário.

O que mudou: a quebra de página do parágrafo que só tem a quebra fica no FIM dele (PageBreak_AlwaysAfter,
não mais no começo). Quando o parágrafo de cima da quebra de seção é só a quebra do usuário, a quebra
derivada da seção não entra (a quebra do usuário já termina a página). Um bloco que vem depois de uma
quebra do usuário no fim do parágrafo não recebe quebra das regras do Word (senão a página em branco
voltava). O arquivo gravado não muda: o parágrafo só com a quebra continua com o w:br type="page"
no mesmo lugar, e a releitura dá o mesmo modelo. Texto digitado num parágrafo que tem a quebra no fim
vira dois parágrafos ao gravar (o texto e, depois, o parágrafo só com a quebra), e a tela mostra a
mesma coisa.

Medido (docs/SPIKES.md, "0.1.22"): dos 14 .docx de Downloads, só o SIM muda, de 15 para 13 páginas
(Word: 14, com a fonte Aptos ausente aqui); o acerto das quebras no SIM vai de 0/0 para 1/1. Nos
outros 13 a contagem e o acerto são os mesmos, e o arquivo salvo tem o mesmo c14n da 0.1.20 nos 14.

Testes: teste_quebras ganhou cinco verificações de paginação e de tela (quebra só no fim, só no
meio, antes de seção, quebra normal, Enter, copiar, colar, rótulo e digitar), com contraprovas. A
suíte tem 3411 verificações (3391 da base e 20 novas). O gate de desempenho ficou dentro do ruído
(docs/SPIKES.md, "0.1.22").