Допотопния език С++ става само за гърмящи програми.

Това ми оправи настроението тази сутрин

Имаче аз съм любител на php за конзолни програми. Много ефективно и подредено може да се пишат. Има си всичко необходимо за четене на опциите, може да се прихващат сигнали като SIGTERM, SIGHUP ... Обработката на текст (с утф8) също е на високо ниво. Има си разните мултибайт mb_* функции и pcre с всякакво мачване на кирилски utf знаци. просто е незаменимо.

Ах, ти говориш за разсейване. Има го и този ефект. Дори в космоса, защото и той не е съвсем празен.

Разсейване е друго нещо. Разсейване е когато се удари в някоя частица и част от енергията се отклони в друга посока. Може например да е перпендикулярно на посоката или въобще в произволна друга посока.

Така е, но пък понякога се срещат със заредени частици и губят част от енергията си. Само за уточнение.

Нарочно не го споменах за да не ставаме много подробни.... Но по този въпрос как и колко във вакума на космоса трябва да питаме астрономите...


Онези сонди касини дето ги изтрелваха към сатурн как успяваха да предават към земята далеко от на майната си  с една мижава чиния. На единия даже чинията не се разтвори правилно и пак упяваше да предава. Даже плутон заснеха.

Напротив! В космоса радиовълните затихват, както във всяка една среда. Причината е проста. Разпространението на радиовълните от един излъчвател се приема за сферично - във всички посоки. Това означава, че за единица време, мощността на сигнала, който е излъчен се разпределя върху цялата сфера. Колкото по-голямо е разстоянието, толкова радиусът на тази сфера се увеличава и така и мощността на излъчениея сигнал намалява, защото се разпределя върху по-голяма площ.

Говоря за затихване (например от средата), а не за разпределение на мощността върху по-голяма или по-малка повърхност.

Както виждаш, споменах, че трябва антената да бъде много насочена (с много тесен лъч).

Естествено, че мощността(силата) на приетия сигнал ще намалява с увеличаване на разстоянието, защото приемната страна ще захваща все по-малка част от излъчения лъч (конус), диаграма на насоченост. Но това не е затихване от средата (вакума). А намаляване силата на сигнала от чиста геометрия.

----
И много много не ми обръщайте внимание,  че тези дни съм на вълна заяждане. И аз не знам що. Сигурно е от времето.

pdftotext изплюва чист txt файл. От това по-просто и по-съвместимо здраве му кажи. След това който иска да си го доработва, редактира и да си го прави в каквото си иска. Ако ще и в база до го вкарва.
Няма как текст в pdf да е стуктуриран подреден и т.н. все пак  pdf-а не е таблица, нито структуриран документ за данни.

[pdftotext]

Да изглежда сканиран, но pdftotext вади целият текст, от всички страници. Пробвах го и работи. Най-вероятно в сканирания документ има вграден и пълния текст, който е OCR-нат още при създаването на документа. (текста наистина изглежда като OCR-нат и се нуждае от ръчна доооправка) Много такива пдф-и срещам напоследък. Може да е работа на Гого, за да може все пак да се търси и между сканираните пдф-и.

А pdftotext при мен (Ценстос) идва от пакета poppler-utils и то май по дифоулт от анакондата.

OCR за този документ не е необходим! Освен ако някой не иска да си поиграе и да го направи по-добре. Например в екстрактнатия техт липсват гръчките думи. Някои липсват други са тотално сбъркани.

Тове едно howto, което съм си го писал за себе си, как се екстрактва текст от pdf.
Не писах по-рано щото сега го намерих.


pdftotext  -nopgbrk -enc UTF-8 PrivateView2012.pdf false.txt

pdftotext  -nopgbrk -enc UTF-8 *pdf - > KF.txt

# когато е на един ред след [for f in *]; и преди [do] се слага точка и запетайка. Но след [do] НЕ се слага ;
# "$f" трябва да е в кавички иначе не може да обработва имена на файлове с паузи по средата. 

shopt -s extglob; for f in *.{pdf,PDF}; do echo -ne "Open: $f\n"; pdftotext -nopgbrk -enc UTF-8 "$f" - >> KF.txt; done



Oбаче мен ме мъчи един  'екзистенциален' въпрос 

има файлове, които си личат че са сканирани. (като този). Обаче като го отворя с някой pdf четец (Okular) ми дава да копирам чист текст в клиборда. Как става това? Дали такива файлове имат вътрешно наред със графиката и вграден текст? или е някакъв динамичен OCR от четеца? Не ми се вярва да е така (динамичен OCR).

Народното творчество тогава много добре си е свършило работата с МИК. Жалко, че не е влязла в никакви стандарти.

Сетили са се да сложат Э, ы, №, най-често използваните гръчки букви, махнали са ненужните графични символи. Много хубава таблица.

А виж за € евро знака не са се сетили Трябвало е да се допитат до Ванга. Обаче майкрософт са се сетили и са го турили в 1251

Значи досовската кодировка въобще НЕ е cp866 а е MIK_(character_set)

Много са различни р,с..ю,я са на друго място.
Чекай с iconv() да я конвентираш. Трябва да си пишеш MIK кодова страница.

Лично аз щях да обработя всички накуп с iconv, както каза Ремо. Ако те е страх от iconv, то може да работиш върху копия. Но определено няма по-бърз начин, а поне аз не съм чувал iconv да се е дънил някога.

Внимателно с този iconv. Имам съмнения. Ползвал съм го от само от PHP страната, което е обръщане към системното iconv() и забелязах, че като срещне непознат символ (или развален utf8 символ) прекъсва по средата - не го скипва и не продължава.
Ако конвентираш от 1251->utf8 теоретично не може да има проблеми, но ако е utf8->1251 ето какво съм си записал.

// !!! не може да се използва iconv('UTF-8', 'windows-1251', $q_string); защото ако види някой знак който iconv() не
// разбира - тя прекъсва стринга до там!!! и се губи информация. iconv() има за тази цел опции //IGNORE но тя работи
// чак при php 5.4.0 Освен това няма опция с какъв символ да се замени '?' неопознатият знак.
//
// !!! Затова са ползва mb_convert_encoding()
//
// Забележи ! посоката на кодирането, е различна при двете функции:
//      utf8 ----> 1251
// iconv('UTF-8', 'windows-1251', $q_string)
//
//               1251 <---- utf8
// mb_convert_encoding($q_string, 'Windows-1251', 'UTF-8')

Пак повртарям това съм го забелязал от към php страната. В конзолното може да го има а може да го няма този проблем. Но трябва да се провери. Нали не искате заради един 'грешен' символ в средата да се отзовете с файл наполовина.

Има и т.нар, "ДОС кирилица".

Всеки път се чудя кои е стандарта или на коя code page мяза най-много. Май е cp866 или пък някакъв IBM code page май беше.

Имам една екзотична книжка на матричен принтер и там най отзад са само такива таблици с екзотични кодировки. Но си спомням, че на една от тях съвпадаше.

Имаше и две досовки програмки за кирилизация CYR и BDS. Те освен че кирилизираха клавитурата, кирилизираха екрана. Та въпросната
"ДОС кирилица" кодировка е тази която използват. И все си мисля, че имаше някаква малка разлика между програмките CYR и BDS. Може би в "псевдографиката"?

[UPDATE t1 SET col1 = col1 + 1;]

Сещам се още един начин. Може да работи а може и да не. Идеята е сравнението да се махне от WHERE частта а да се направи с вградена функция в SET-a.

Код:

UPDATE t
  SET f = if(f = 0, 123, f) ;

според https://dev.mysql.com/doc/refman/8.0/en/update.html
ако имаме следния примерен код:

if you access a column from the table to be updated in an expression, UPDATE uses the current value of the column. For example, the following statement sets col1 to one more than its current value:
UPDATE t1 SET col1 = col1 + 1;

то mysql-a в дясната част използва текущата (непромената) стойност на полето. т.е col1 (f) ни е гарантирано!

така ще се опита да ъпдейтне всичките редове, щото няма WHERE, но само някои, които отговарят на условието ще се ъпдейтнат. (То пак може да имаме  WHERE с разни други условия)
Но пък на друго място е казано, че

If you set a column to the value it currently has, MySQL notices this and does not update it.

така, че ще работи бързо. Тези if(), case ..... изобщо всичките му вградени функции са много бързи.

Аз със kate редовно конвентирам файлове от 1251 към utf8. Отваряш файла, виждаш му каква е правилната/текущата кодировка, има едно view вътре в редактора с което може да превключваш динамично кодировките (за екрана! Само за виждане, не за запис) и след това SAVE AS и тук вече избираш Utf8.

И из това се чудих защо да не може така.... Ама навсякъде казват че не можело на едно и също поле?. Кое ще изпълни първо - условието или ъпдейта. Няма как да знаеш как работи вътрешно.

[multi-table update]

Такова не съм правил. обаче.... тук

https://dev.mysql.com/doc/refman/8.0/en/update.html

след средата на страницата (най-отдолу) има описан такъв случай. с три работещи примера. На мен най ми хареса най-последния (който е най-отдолу)

Код:

UPDATE items,
       (SELECT id, retail / wholesale AS markup, quantity FROM items)
       AS discounted
    SET items.retail = items.retail * 0.9
    WHERE discounted.markup >= 1.3
    AND discounted.quantity < 100
    AND items.id = discounted.id;

Сега  доколкото разбирам ключа от бараката е следния:
1. Да се ползва multi-table update, като втората таблица, която е пак същата е описана като alias. (AS discounted)

UPDATE items, (...) AS discounted  SET ....

2. и друга хитрост има, че sub-query -то (SELECT id,....) е преместено в частта където се описват таблиците, по които ще се действа - т.е FROM частта. (То тука FROM няма, има UPDATE, но все тая..)

https://www.mysqltutorial.org/mysql-subquery/

MySQL subquery in the FROM clause
-----------------
When you use a subquery in the FROM clause, the result set returned from a subquery is used as a temporary table. This table is referred to as a derived table or materialized subquery.

А аз бих избрал Пенелопе Крус.